idnits 2.17.1 draft-jenkins-jscalendar-04.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 (January 12, 2018) is 2294 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 2076 -- Looks like a reference, but probably isn't: '2' on line 2078 -- Looks like a reference, but probably isn't: '3' on line 2081 -- Looks like a reference, but probably isn't: '4' on line 2083 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Calendaring extensions N. Jenkins 3 Internet-Draft R. Stepanek 4 Intended status: Standards Track FastMail 5 Expires: July 16, 2018 January 12, 2018 7 JSCalendar: A JSON representation of calendar data 8 draft-jenkins-jscalendar-04 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. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 16, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Relation to the iCalendar format . . . . . . . . . . . . 4 54 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5 55 2. JSCalendar objects . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Structure of JSCalendar objects . . . . . . . . . . . . . . . 6 60 3.1. Type signatures . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2.1. UTCDate . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2.2. LocalDate . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.3. Duration . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2.4. PatchObject . . . . . . . . . . . . . . . . . . . . . 7 66 3.2.5. Normalisation and equivalence . . . . . . . . . . . . 8 67 3.3. Custom property extensions and values . . . . . . . . . . 9 68 4. Common JSCalendar properties . . . . . . . . . . . . . . . . 9 69 4.1. Metadata properties . . . . . . . . . . . . . . . . . . . 9 70 4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1.2. uid . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.3. relatedTo . . . . . . . . . . . . . . . . . . . . . . 10 73 4.1.4. prodId . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1.5. created . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.1.6. updated . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.1.7. sequence . . . . . . . . . . . . . . . . . . . . . . 11 77 4.1.8. method . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.2. What and where properties . . . . . . . . . . . . . . . . 11 79 4.2.1. title . . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.2.2. description . . . . . . . . . . . . . . . . . . . . . 11 81 4.2.3. htmlDescription . . . . . . . . . . . . . . . . . . . 12 82 4.2.4. locations . . . . . . . . . . . . . . . . . . . . . . 12 83 4.2.5. links . . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.2.6. locale . . . . . . . . . . . . . . . . . . . . . . . 15 85 4.2.7. keywords . . . . . . . . . . . . . . . . . . . . . . 15 86 4.2.8. categories . . . . . . . . . . . . . . . . . . . . . 15 87 4.2.9. color . . . . . . . . . . . . . . . . . . . . . . . . 16 88 4.3. Recurrence properties . . . . . . . . . . . . . . . . . . 16 89 4.3.1. recurrenceRule . . . . . . . . . . . . . . . . . . . 16 90 4.3.2. recurrenceOverrides . . . . . . . . . . . . . . . . . 18 91 4.4. Sharing and scheduling properties . . . . . . . . . . . . 19 92 4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 19 93 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 19 94 4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 19 95 4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 20 96 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 21 97 4.5. Alerts properties . . . . . . . . . . . . . . . . . . . . 24 98 4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 24 99 4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 25 100 4.6. Multilingual properties . . . . . . . . . . . . . . . . . 27 101 4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 27 102 5. Type-specific JSCalendar properties . . . . . . . . . . . . . 28 103 5.1. JSEvent properties . . . . . . . . . . . . . . . . . . . 28 104 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 28 105 5.1.2. timeZone . . . . . . . . . . . . . . . . . . . . . . 28 106 5.1.3. duration . . . . . . . . . . . . . . . . . . . . . . 28 107 5.1.4. isAllDay . . . . . . . . . . . . . . . . . . . . . . 29 108 5.1.5. status . . . . . . . . . . . . . . . . . . . . . . . 29 109 5.2. JSTask properties . . . . . . . . . . . . . . . . . . . . 29 110 5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 29 111 5.2.2. start . . . . . . . . . . . . . . . . . . . . . . . . 30 112 5.2.3. timeZone . . . . . . . . . . . . . . . . . . . . . . 30 113 5.2.4. estimatedDuration . . . . . . . . . . . . . . . . . . 30 114 5.2.5. completed . . . . . . . . . . . . . . . . . . . . . . 30 115 5.2.6. isAllDay . . . . . . . . . . . . . . . . . . . . . . 30 116 5.2.7. progress . . . . . . . . . . . . . . . . . . . . . . 31 117 5.2.8. status . . . . . . . . . . . . . . . . . . . . . . . 31 118 5.3. JSGroup properties . . . . . . . . . . . . . . . . . . . 32 119 5.3.1. entries . . . . . . . . . . . . . . . . . . . . . . . 32 120 5.3.2. source . . . . . . . . . . . . . . . . . . . . . . . 32 121 6. Conversion from and to iCalendar . . . . . . . . . . . . . . 33 122 6.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 33 123 6.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 33 124 6.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 34 125 6.4. Common properties . . . . . . . . . . . . . . . . . . . . 35 126 6.5. Locations and participants . . . . . . . . . . . . . . . 37 127 6.6. Unknown properties . . . . . . . . . . . . . . . . . . . 39 128 7. JSCalendar object examples . . . . . . . . . . . . . . . . . 39 129 7.1. Simple JSEvent . . . . . . . . . . . . . . . . . . . . . 39 130 7.2. Recurring JSEvent with exception . . . . . . . . . . . . 40 131 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 132 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 133 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 134 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 135 11.1. Normative References . . . . . . . . . . . . . . . . . . 42 136 11.2. Informative References . . . . . . . . . . . . . . . . . 44 137 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 140 1. Introduction 142 This document defines a data model for calendar event and task 143 objects, or groups of such objects, in electronic calendar 144 applications and systems. It aims to be unambiguous, extendable and 145 simple to process. 147 The key design considerations for this data model are as follows: 149 o The attributes of the calendar entry represented must be described 150 as a simple key-value pair, reducing complexity of its 151 representation. 153 o The data model should avoid all ambiguities and make it difficult 154 to make mistakes during implementation. 156 o Most of the initial set of attributes should be taken from the 157 iCalendar data format ([RFC5545], also see Section 1.1), but the 158 specification should add new attributes or value types, or not 159 support existing ones, where appropriate. Conversion between the 160 data formats need not fully preserve semantic meaning. 162 o Extensions, such as new properties and components, MUST NOT lead 163 to requiring an update to this document. 165 The representation of this data model is defined in the I-JSON format 166 [RFC7493], which is a strict subset of the JavaScript Object Notation 167 (JSON) Data Interchange Format [RFC8259]. Using JSON mostly is a 168 pragmatic choice: its widespread use should help to speed up 169 JSCalendar adoption and a wide range of production-ready JSON 170 implementations allows to decrease interoperability issues. 172 1.1. Relation to the iCalendar format 174 The iCalendar data format [RFC5545], a widely deployed interchange 175 format for calendaring and scheduling data, has served calendaring 176 vendors for a long while, but contains some ambiguities and pitfalls 177 that can not be overcome without backward-incompatible changes. 179 For example, iCalendar defines various formats for local times, UTC 180 time and dates, which confuses new users. Other sources for errors 181 are the requirement for custom time-zone definitions within a single 182 calendar component, as well as the iCalendar format itself; the 183 latter causing interoperability issues due to misuse of CR LF 184 terminated strings, line continuations and subtle differences between 185 iCalendar parsers. Lastly, up until recently the iCalendar format 186 did not allow to express the difference between two calendar 187 components, which results in verbose exchanges during scheduling. 189 Some of these issues were addressed by the jCal [RFC7265] format, 190 which is a direct mapping between iCalendar and JSON. However, it 191 did not attempt to extend or update iCalendar semantics. 193 1.2. Notational Conventions 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. 199 The underlying format used for this specification is JSON. 200 Consequently, the terms "object" and "array" as well as the four 201 primitive types (strings, numbers, booleans, and null) are to be 202 interpreted as described in Section 1 of[RFC8259]. 204 Some examples in this document contain "partial" JSON documents used 205 for illustrative purposes. In these examples, three periods "..." 206 are used to indicate a portion of the document that has been removed 207 for compactness. 209 2. JSCalendar objects 211 This section describes the calendar object types specified by 212 JSCalendar. 214 2.1. JSEvent 216 MIME type: "application/calendar+json;type=jsevent" 218 A JSEvent represents a scheduled amount of time on a calendar, 219 typically a meeting, appointment, reminder or anniversary. Multiple 220 participants may partake in the event at multiple locations. 222 The @type (Section 4.1.1) property value MUST be "jsevent". 224 2.2. JSTask 226 MIME type: "application/calendar+json;type=jstask" 228 A JSTask represents an action-item, assignment, to-do or work item . 230 The @type (Section 4.1.1) property value MUST be "jstask". 232 A JSTask may start and be due at certain points in time, may take 233 some estimated time to complete and may recur; none of which is 234 required. This notably differs from JSEvent (Section 2.1) which is 235 required to start at a certain point in time and typically takes some 236 non-zero duration to complete. 238 2.3. JSGroup 240 MIME type: "application/calendar+json;type=jsgroup" 242 A JSGroup is a collection of JSEvent (Section 2.1) and JSTask 243 (Section 2.2) objects. Typically, objects are grouped by topic (e.g. 244 by keywords) or calendar membership. 246 The @type (Section 4.1.1) property value MUST be "jsgroup". 248 3. Structure of JSCalendar objects 250 A JSCalendar object is a JSON object, which MUST be valid I-JSON (a 251 stricter subset of JSON), as specified in [RFC8259]. Property names 252 and values are case-sensitive. 254 The object has a collection of properties, as specified in the 255 following sections. Unless otherwise specified, all properties are 256 optional; omitted properties MUST be treated identically to if that 257 property had the value of "null", unless otherwise specified. 259 3.1. Type signatures 261 Types signatures are given for all JSON objects in this document. 262 The following conventions are used: 264 o "Boolean|String": The value is either a JSON "Boolean" value, or a 265 JSON "String" value. 267 o "Foo": Any name that is not a native JSON type means an object for 268 which the properties (and their types) are defined elsewhere 269 within this document. 271 o "Foo[]": An array of objects of type "Foo". 273 o "String[Foo]": A JSON "Object" being used as a map (associative 274 array), where all the values are of type "Foo". 276 3.2. Data Types 278 In addition to the standard JSON data types, the following data types 279 are used in this specification: 281 3.2.1. UTCDate 283 This is a string in [RFC3339] "date-time" format, with the further 284 restrictions that any letters MUST be in upper-case, the time 285 component MUST be included and the time MUST be in UTC. Fractional 286 second values MUST NOT be included unless non-zero and MUST NOT have 287 trailing zeros, to ensure there is only a single representation for 288 each date-time. 290 For example "2010-10-10T10:10:10.003Z" is OK, but 291 "2010-10-10T10:10:10.000Z" is invalid and MUST be encoded as 292 "2010-10-10T10:10:10Z". 294 In common notation, it should be of the form "YYYY-MM-DDTHH:MM:SSZ". 296 3.2.2. LocalDate 298 This is a date-time string _with no time-zone/offset information_. 299 It is otherwise in the same format as UTCDate: "YYYY-MM-DDTHH:MM:SS". 300 The time-zone to associate the LocalDate with comes from an 301 associated property, or if no time-zone is associated it defines 302 _floating time_. Floating date-times are not tied to any specific 303 time-zone. Instead, they occur in every timezone at the same _wall- 304 clock_ time (as opposed to the same instant point in time). 306 3.2.3. Duration 308 A duration is represented by a subset of ISO8601 duration format, as 309 specified by the following ABNF: 311 dur-secfrac = "." 1*DIGIT 312 dur-second = 1*DIGIT [dur-secfrac] "S" 313 dur-minute = 1*DIGIT "M" [dur-second] 314 dur-hour = 1*DIGIT "H" [dur-minute] 315 dur-time = "T" (dur-hour / dur-minute / dur-second) 316 dur-day = 1*DIGIT "D" 318 duration = "P" (dur-day [dur-time] / dur-time) 320 In addition, the duration MUST NOT include fractional second values 321 unless the fraction is non-zero. A zero duration MUST be represented 322 as "P0D". 324 3.2.4. PatchObject 326 A *PatchObject* is of type "String[*|null]", and represents an 327 unordered set of patches on a JSON object. The keys are a path in a 328 subset of [RFC6901] JSON pointer format, with an implicit leading "/" 329 (i.e. prefix each key with "/" before applying the JSON pointer 330 evaluation algorithm). 332 A patch within a PatchObject is only valid, if all of the following 333 conditions apply: 335 1. The pointer MUST NOT reference inside an array (i.e. it MUST NOT 336 insert/delete from an array; the array MUST be replaced in its 337 entirety instead). 339 2. When evaluating a path, all parts prior to the last (i.e. the 340 value after the final slash) MUST exist. 342 3. There MUST NOT be two patches in the PatchObject where the 343 pointer of one is the prefix of the pointer of the other, e.g. 344 "alerts/1/offset" and "alerts". 346 The value associated with each pointer is either: 348 o "null": Remove the property from the patched object. If not 349 present in the parent, this a no-op. 351 o Anything else: The value to replace the inherited property on the 352 patch object with (if present) or add to the property (if not 353 present). 355 Implementations MUST reject a PatchObject if any of its patches are 356 invalid. 358 3.2.5. Normalisation and equivalence 360 JSCalendar aims to provide unambiguous definitions for value types 361 and properties, but does not define a general normalisation or 362 equivalence method for JSCalendar objects and types. This is because 363 the notion of equivalence might range from byte-level equivalence to 364 semantic equivalence, depending on the respective use case (for 365 example, the CalDAV protocol [RFC4791] requires octet equivalence of 366 the encoded calendar object to determine ETag equivalence). 368 Normalisation of JSCalendar objects is hindered because of the 369 following reasons: 371 o Custom JSCalendar properties may contain arbitrary JSON values, 372 including arrays. However, equivalence of arrays might or might 373 not depend on the order of elements, depending on the respective 374 property definition. 376 o Several JSCalendar property values are defined as URIs and MIME 377 types, but normalisation of these types is inherently protocol and 378 scheme-specific, depending on the use-case of the equivalence 379 definition (see section 6 of [RFC3986]). 381 Considering this, the definition of equivalence and normalisation is 382 left to client and server implementations and to be negotiated by a 383 calendar exchange protocol or defined by another RFC. 385 3.3. Custom property extensions and values 387 Vendors MAY add additional properties to the calendar object to 388 support their custom features. The names of these properties MUST be 389 prefixed with a domain name controlled by the vendor to avoid 390 conflict, e.g. "example.com/customprop". 392 Some JSCalendar properties allow vendor-specific value extensions. 393 If so, vendor specific values MUST be prefixed with a domain name 394 controlled by the vendor, e.g. "example.com/customrel", unless 395 otherwise noted. 397 4. Common JSCalendar properties 399 This section describes the properties that are common to the various 400 JSCalendar object types. Specific JSCalendar object types may only 401 support a subset of these properties. The object type definitions in 402 section Section 5 describe the set of supported properties per type. 404 4.1. Metadata properties 406 4.1.1. @type 408 Type: "String" 410 Specifies the type which this object represents. This MUST be one of 411 the following values, registered in a future RFC, or a vendor- 412 specific value: 414 o "jsevent": a JSCalendar event (Section 2.1). 416 o "jstask": a JSCalendar task (Section 2.2). 418 o "jsgroup": a JSCalendar group (Section 2.3). 420 A valid JSCalendar object MUST include this property. 422 4.1.2. uid 424 Type: "String" 426 A globally unique identifier, used to associate the object as the 427 same across different systems, calendars and views. The value of 428 this property MUST be unique across _all_ JSCalendar objects, even if 429 they are of different type. [RFC4122] describes a range of 430 established algorithms to generate universally unique identifiers 431 (UUID), and the random or pseudo-random version is recommended to 432 use. 434 A valid JSCalendar object MUST include this property. 436 4.1.3. relatedTo 438 Type: "String[Relation]|null" 440 Relates the object to other JSCalendar objects. This is represented 441 as a map of the uids of the related objects to information about the 442 relation. 444 A *Relation* object has the following properties: 446 o *relation*: "String[]" Describes how the linked object is related 447 to this object. 449 The strings in the array MUST each be at most one of the following 450 values, registered in a future RFC, or a vendor-specific value: 452 * "first": The linked object is the first in the series this 453 object is part of. 455 * "next": The linked object is the next in the series this object 456 is part of. 458 * "child": The linked object is a subpart of this object. 460 * "parent": This object is part of the overall linked object. 462 If an object is split to make a "this and future" change to a 463 recurrence, the original object MUST be truncated to end at the 464 previous occurrence before this split, and a new object created to 465 represent all the objects after the split. A "relation=["next"]" 466 relatedTo property MUST be set on the original object with the uid of 467 the new object. A "relation=["first"]" relatedTo property with the 468 UID of the first object in the series MUST be set on the new object. 469 Clients can then follow these UIDs to get the complete set of objects 470 if the user wishes to modify them all at once. 472 4.1.4. prodId 474 Type: "String|null" 476 The identifier for the product that created the JSCalendar object. 478 The vendor of the implementation SHOULD ensure that this is a 479 globally unique identifier, using some technique such as an FPI 480 value, as defined in [ISO.9070.1991]. 482 This property SHOULD NOT be used to alter the interpretation of an 483 JSCalendar object beyond the semantics specified in this document. 484 For example, it is not to be used to further the understanding of 485 non-standard properties. 487 4.1.5. created 489 Type: "UTCDate|null" 491 The date and time this object was initially created. 493 4.1.6. updated 495 Type: "UTCDate" 497 The date and time the data in this object was last modified. 499 4.1.7. sequence 501 Type: "Number" (Defaults to "0" if omitted) 503 Initially zero, this MUST be a non-negative integer that is 504 monotonically incremented each time a change is made to the object. 506 4.1.8. method 508 Type: "String|null" 510 The iTIP ([RFC5546]) method, in lower-case. Used for scheduling. 512 4.2. What and where properties 514 4.2.1. title 516 Type: "String" (Defaults to the empty string if omitted) 518 A short summary of the object. 520 4.2.2. description 522 Type: "String" (Defaults to the empty string if omitted) 524 A longer form description of the object. This is plain text, but a 525 client SHOULD attempt to hyperlink URLs when displaying it. 527 4.2.3. htmlDescription 529 Type: "String" (Defaults to the empty string if omitted) 531 A longer form rich-text description of the object. This is HTML text 532 [1] and allows to reference resources in the *links* property by use 533 of CID URLs (see [RFC2392]). To convert a CID URL to the *cid* 534 property value of a *Link* object, implementations MUST follow the 535 conversion described in section 2 of [RFC2392]. Implementations MAY 536 choose not to follow untrusted external CID URLs referenced in the 537 *links* property, in which case they MUST treat the *htmlDescription* 538 property as if omitted. Implementations MUST preserve the value of 539 this property, even if it contains untrusted links. 541 4.2.4. locations 543 Type: "String[Location]|null" 545 A map of location ids to Location objects, representing locations 546 associated with the object. A location id may be any string and need 547 only be unique to this object, although a UUID is a practical choice. 549 A *Location* object has the following properties. All properties are 550 optional, but every Location object MUST have at least one property: 552 o *name*: "String" The human-readable name of the location. 554 o *description*: "String" Human-readable instructions for accessing 555 this location. This may be an address, set of directions, door 556 access code, etc. 558 o *rel*: "String" The relation type of this location to the 559 JSCalendar object. 561 This MUST be either one of the following values, registered in a 562 future RFC, or a vendor-specific value. Any value the client or 563 server doesn't understand should be treated the same as "unknown". 565 * "start": The JSCalendar object starts at this location. 567 * "end": The JSCalendar object ends at this location. 569 * "virtual": This is not a physical location (e.g. this location 570 is an online chat room where people will meet). 572 * "unknown": The relation of this location to the calendar object 573 is unknown. 575 o *features*: "String[]|null" The features supported by this 576 location. 578 The strings in the array MUST each be either one of the following 579 values, registered in a future RFC, or a vendor-specific value. 580 Any value the client or server doesn't understand should be 581 ignored, but preserved. 583 The features supported by locations with rel-type "virtual" are: 585 * "audio": audio conferencing 587 * "chat": chat or instant messaging 589 * "screen": screen sharing 591 * "video": video conferencing 593 * any vendor-prefixed custom value 595 o *timeZone*: "String|null" (Defaults to "null" if omitted) A time- 596 zone for this location. 598 If "null", the *timeZone* from the JSCalendar object MUST be 599 presumed when a time-zone is needed in relation to this location. 600 This property MUST be "null" if the *rel* property value of this 601 location is "start". 603 o *coordinates*: "String" An [RFC5870] "geo:" URI for the location. 605 o *uri*: "String" A URI that represents how to connect to this 606 location. 608 This may be a telephone number (represented as 609 "tel:+1-555-555-555") for a teleconference, a web address for 610 online chat, or any custom URI. 612 o *linkIds*: "String[]|null" A list of ids for links to alternate 613 representations of this location. 615 For example, an alternative representation could be in vCard 616 format. If a given value does not correspond to any link id in 617 the links property of the instance, this MUST be ignored. 619 4.2.5. links 621 Type: "String[Link]|null" 623 A map of link ids to Link objects, representing external resources 624 associated with the object. A link id may be any string and need 625 only be unique to this object, although the href or a UUID are 626 practical choices. 628 A *Link* object has the following properties: 630 o *href*: "String" A URI from which the resource may be fetched. 632 This MAY be a "data:" URL, but it is recommended that the file be 633 hosted on a server to avoid embedding arbitrary large data in 634 JSCalendar object instances. 636 o *cid* "String|null" The id used within the *htmlDescription* 637 property to reference this link. 639 If not null, this MUST be a valid Content-ID MIME header value 640 (see [RFC2392]). The identifier MUST be unique within this 641 JSCalendar object but has no meaning beyond that. Specifically, 642 it MAY be different from the *Link* object identifier in the 643 enclosing *links* property. 645 o *type*: "String|null"(optional, defaults to "null") The content- 646 type [RFC6838] of the resource, if known. 648 o *size*: "Number|null"(optional, defaults to "null") The size, in 649 bytes, of the resource when fully decoded (i.e. the number of 650 bytes in the file the user would download), if known. 652 o *rel*: "String"(optional, defaults to "related") Identifies the 653 relation of the linked resource to the object. The value MUST be 654 a registered relation type (see [RFC8288] and IANA Link Relations 655 [2]). 657 Links with a rel of "enclosure" SHOULD be considered by the client 658 as attachments for download. 660 Links with a rel of "describedby" SHOULD be considered by the 661 client to be an alternate representation of the description and 662 HTML description. 664 Links with a rel of "icon" SHOULD be considered by the client to 665 be an image that it MAY use when presenting the calendar data to a 666 user. The *properties* object of this link MAY include a 667 "display" property indicating the intended purpose of this image. 668 If included, the value MUST be either one of the following values, 669 registered in a future RFC, or a vendor-specific value. 671 * "badge": an image inline with the title of the object 673 * "graphic": a full image replacement for the object itself 675 * "fullsize": an image that is used to enhance the object 677 * "thumbnail": a smaller variant of "fullsize " to be used when 678 space for the image is constrained 680 o *title*: "String|null"(optional, defaults to "null") A human- 681 readable description of the resource. 683 o *properties*: "String[String|null]|null"(optional, defaults to 684 "null") Extra metadata submitted by clients about a link. Server 685 implementations MUST preserve these properties. 687 The keys are as defined in this document, as defined in a future 688 RFC, or URIs that should be owned by the client author to avoid 689 conflicts. 691 4.2.6. locale 693 Type: "String|null" 695 The [RFC5646] language tag that best describes the locale used for 696 the calendar object, if known. 698 4.2.7. keywords 700 Type: "String[]|null" 702 A list of keywords or tags related to the object. The values are 703 free-form and do not have to follow any particular structure. 705 4.2.8. categories 707 Type: "String[]|null" 709 Specifies the categories related to the calendar object. Array 710 values MUST be URIs. In contrast to *keywords*, categories typically 711 are structured. 713 For example, a vendor owning the domain "example.com" might define 714 the categories "http://example.com/categories/sports/american- 715 football"" and "http://example.com/categories/music/r-b". 717 4.2.9. color 719 Type: "String" 721 Specifies a color clients MAY use when displaying this calendar 722 object. The value is a case-insensitive color name taken from the 723 CSS3 set of names, defined in Section 4.3 of W3C.REC- 724 css3-color-20110607 [3] or a CSS3 RGB color hex value. 726 4.3. Recurrence properties 728 4.3.1. recurrenceRule 730 Type: "Recurrence" 732 Defines a recurrence rule (repeating pattern) for recurring calendar 733 objects. 735 A *Recurrence* object is a JSON object mapping of a RECUR value type 736 in iCalendar, see [RFC5545] and[RFC7529]. Objects recur by applying 737 the recurrence rule (and *recurrenceOverrides*) to the *start* date/ 738 time. A JSTask (Section 2.2) without a *start* property value recurs 739 by its *due* date/time, if defined. 741 A Recurrence object has the following properties: 743 o *frequency*: "String" This MUST be one of the following values: 745 * "yearly" 747 * "monthly" 749 * "weekly" 751 * "daily" 753 * "hourly" 755 * "minutely" 757 * "secondly" 759 To convert from iCalendar, simply lower-case the FREQ part. 761 o *interval*: "Number"(optional, defaults to "1") The INTERVAL part 762 from iCal. If included, it MUST be an integer "x >= 1". 764 o *rscale*: "String"(optional, defaults to ""gregorian"") The RSCALE 765 part from iCalendar RSCALE [RFC7529], converted to lower-case. 767 o *skip*: "String"(optional, defaults to ""omit"") The SKIP part 768 from iCalendar RSCALE [RFC7529], converted to lower-case. 770 o *firstDayOfWeek*: "String"(optional, defaults to ""mo"") The WKST 771 part from iCalendar, represented as a lower-case abbreviated two- 772 letter English day of the week. If included, it MUST be one of 773 the following values: ""mo"|"tu"|"we"|"th"|"fr"|"sa"|"su"". 775 o *byDay*: "NDay[]"(optional) An *NDay* object has the following 776 properties: 778 * *day*: "String" The day-of-the-week part of the BYDAY value in 779 iCalendar, lower-cased. MUST be one of the following values: 780 ""mo"|"tu"|"we"|"th"|"fr"|"sa"|"su"". 782 * *nthOfPeriod*: "Number"(optional) The optional ordinal part of 783 the BYDAY value in iCalendar (e.g. ""+1"" or ""-3""). If 784 present, rather than representing every occurrence of the 785 weekday defined in the *day* property of this *NDay*, it 786 represents only a specific instance within the recurrence 787 period. The value can be positive or negative, but MUST NOT be 788 zero. A negative integer means nth-last of period. 790 o *byMonthDay*: "Number[]"(optional) The BYMONTHDAY part from 791 iCalendar. The array MUST have at least one entry if included. 793 o *byMonth*: "String[]"(optional) The BYMONTH part from iCalendar. 794 Each entry is a string representation of a number, starting from 795 "1" for the first month in the calendar (e.g. ""1" " means 796 ""January"" with Gregorian calendar), with an optional ""L"" 797 suffix (see [RFC7529]) for leap months (this MUST be upper-case, 798 e.g. ""3L""). The array MUST have at least one entry if included. 800 o *byYearDay*: "Number[]"(optional) The BYYEARDAY part from 801 iCalendar. The array MUST have at least one entry if included. 803 o *byWeekNo*: "Number[]"(optional) The BYWEEKNO part from iCalendar. 804 The array MUST have at least one entry if included. 806 o *byHour*: "Number[]"(optional) The BYHOUR part from iCalendar. 807 The array MUST have at least one entry if included. 809 o *byMinute*: "Number[]"(optional) The BYMINUTE part from iCalendar. 810 The array MUST have at least one entry if included. 812 o *bySecond*: "Number[]"(optional) The BYSECOND part from iCalendar. 813 The array MUST have at least one entry if included. 815 o *count*: "Number"(optional) The COUNT part from iCalendar. This 816 MUST NOT be included if an *until* property is specified. 818 o *until*: "LocalDate"(optional) The UNTIL part from iCalendar. 819 This MUST NOT be included if a *count* property is specified. 820 Note, as in iCalendar, this date is presumed to be in the time- 821 zone specified in *timeZone*. It is not a UTC time. 823 4.3.2. recurrenceOverrides 825 Type: "LocalDate[PatchObject|null]|null" 827 A map of the recurrence-ids (the date-time of the start of the 828 occurrence) to either "null", to indicate the occurrence should be 829 deleted, or an object of patches to apply to the generated occurrence 830 object. 832 If the recurrence-id does not match an expanded start date from a 833 recurrence rule, it is to be treated as an additional occurrence 834 (like an RDATE from iCalendar). The patch object may often be empty 835 in this case. 837 By default, an occurrence inherits all properties from the main 838 object except the start (or due) date-time, which is shifted to the 839 new start time. However, individual properties of the occurrence can 840 be modified by a patch, or multiple patches. 842 A pointer in the PatchObject MUST NOT start with one of the following 843 prefixes; any patch with such a key MUST be ignored: 845 o @type 847 o uid 849 o relatedTo 851 o prodId 853 o method 855 o isAllDay 856 o recurrenceRule 858 o recurrenceOverrides 860 o replyTo 862 4.4. Sharing and scheduling properties 864 4.4.1. priority 866 Type: "Number"(defaults to "0" if omitted) 868 Specifies a priority for the calendar object. This may be used as 869 part of scheduling systems to help resolve conflicts for a time 870 period. 872 The priority is specified as an integer in the range 0 to 9. A value 873 of 0 specifies an undefined priority. A value of 1 is the highest 874 priority. A value of 2 is the second highest priority. Subsequent 875 numbers specify a decreasing ordinal priority. A value of 9 is the 876 lowest priority. Other integer values are reserved for future use. 878 4.4.2. freeBusyStatus 880 Type: "String"(defaults to "busy" if omitted) 882 Specifies how this property should be treated when calculating free- 883 busy state. The value MUST be one of: 885 o ""free"": The object should be ignored when calculating whether 886 the user is busy. 888 o ""busy"": The object should be included when calculating whether 889 the user is busy. 891 4.4.3. privacy 893 Type: "String"(defaults to "public" if omitted) 895 Calendar objects are normally collected together and may be shared 896 with other users. The privacy property allows the object owner to 897 indicate that it should not be shared, or should only have the time 898 information shared but the details withheld. Enforcement of the 899 restrictions indicated by this property are up to the 900 implementations. 902 This property MUST NOT affect the information sent to scheduled 903 participants; it is only interpreted when the object is shared as 904 part of a shared calendar. 906 The value MUST be either one of the following values, registered in a 907 future RFC, or a vendor-specific value. Vendor specific values MUST 908 be prefixed with a domain name controlled by the vendor, e.g. 909 "example.com/topsecret". Any value the client or server doesn't 910 understand should be preserved but treated as equivalent to 911 "private". 913 o "public": The full details of the object are visible to those whom 914 the object's calendar is shared with. 916 o "private": The details of the object are hidden; only the basic 917 time and metadata is shared. Implementations MUST ensure the 918 following properties are stripped when the object is accessed by a 919 sharee: 921 * title 923 * description 925 * htmlDescription 927 * locations 929 * links 931 * locale 933 * localizations 935 * participants 937 * replyTo 939 In addition, any patches in "recurrenceOverrides" whose key is 940 prefixed with one of the above properties MUST be stripped. 942 o "secret": The object is hidden completely (as though it did not 943 exist) when the calendar is shared. 945 4.4.4. replyTo 947 Type: "String[String]|null" 948 Represents methods by which a participant may RSVP to the organizer 949 of the calendar object. The keys in the property value are the 950 available methods. The value is a URI to use that method. Future 951 methods may be defined in future specifications; a calendar client 952 MUST ignore any method it does not understand. 954 The following methods are defined: 956 o "imip": The organizer accepts an iMIP [RFC6047] response. The 957 value MUST be a "mailto:" URI. 959 o "web": There is a web page where the user may submit an RSVP using 960 their browser. The value MUST be an "http:" or "https:" URI 961 Template ([RFC6570]) in level 1 format. The template MAY contain 962 variables that MUST be expanded from the JSCalendar object as 963 defined in table Table 1. Calendar clients SHOULD be prepared to 964 handle authentication requests from the respective web page and 965 for the participant email, but this specification does not mandate 966 any specific mechanism. 968 +--------------+----------------------------------------------------+ 969 | Variable | Expand to | 970 +--------------+----------------------------------------------------+ 971 | email | The *email* property value of the replying | 972 | | *Participant* object. | 973 | | | 974 | uid | The *uid* property value of the JSCalendar object. | 975 | | | 976 | sequence | The *sequence* property value of the JSCalendar | 977 | | object. | 978 | | | 979 | recurrenceId | The recurrence-id when replying for a single | 980 | | occurrence of a recurring JSCalendar object. The | 981 | | value is the date-time of the non-overridden start | 982 | | as determined by expanding the *recurrenceRule* of | 983 | | the JSCalendar object. | 984 +--------------+----------------------------------------------------+ 986 Table 1: replyTo URI Template variables 988 4.4.5. participants 990 Type: "String[Participant]|null" 992 A map of participant ids to participants, describing their 993 participation in the calendar object. A participant id may be any 994 string and need only be unique to this calendar object; the email 995 address of the participant is a good choice. 997 A *Participant* object has the following properties. Properties are 998 mandatory unless marked otherwise: 1000 o *name*: "String" The display name of the participant (e.g. "Joe 1001 Bloggs"). 1003 o *email*: "String" The email address for the participant. 1005 o *kind*: "String"(optional, defaults to "unknown") What kind of 1006 entity this participant is. 1008 This MUST be either one of the following values, registered in a 1009 future RFC, or a vendor-specific value. Any value the client or 1010 server doesn't understand should be treated the same as "unknown". 1012 * "individual": a single person 1014 * "group": a collection of people invited as a whole 1016 * "resource": a non-human resource, e.g. a projector 1018 * "location": a physical location involved in the calendar object 1019 that needs to be scheduled, e.g. a conference room. 1021 * "unknown": no information is available about the kind of this 1022 participant. 1024 o *roles*: "String[]" A list of roles that this participant fulfils. 1026 At least one value MUST be specified for the participant. This 1027 MUST be either one of the following values, registered in a future 1028 RFC, or a vendor-specific value. Any value the client or server 1029 doesn't understand should be preserved but ignored. 1031 * "owner": The participant is an owner of the object, and allowed 1032 to make alterations to any part of it. 1034 * "attendee": The participant is an attendee of the calendar 1035 object. Attendees are only allowed to alter their own 1036 participation. 1038 * "chair": The participant is in charge of the calendar object 1039 when it occurs. 1041 o *locationId*: "String|null"(optional, defaults to "null") The 1042 location at which this participant is expected to be attending. 1044 If the value does not correspond to any location id in the 1045 locations property of the instance, this MUST be treated the same 1046 as if the participant's locationId were specified as null. 1048 o *rsvpResponse*: "String"(optional, defaults to "needs-action") The 1049 RSVP response, if any, of this participant. 1051 The value MUST be either one of the following values, registered 1052 in a future RFC, or a vendor-specific value: 1054 * "needs-action": No status yet set by the participant. 1056 * "accepted": The invited participant will participate. 1058 * "declined": The invited participant will not participate. 1060 * "tentative": The invited participant may participate. 1062 o *participation*: "String"(optional, defaults to "required") The 1063 required participation of this participant. 1065 The value MUST be either one of the following values, registered 1066 in a future RFC, or a vendor-specific value. Any value the client 1067 or server doesn't understand should be treated the same as 1068 "required". 1070 * "non-participant": Indicates a participant who is copied for 1071 information purposes only. 1073 * "optional": Indicates a participant whose participation is 1074 optional. 1076 * "required": Indicates a participant whose participation is 1077 required. 1079 o *rsvpWanted*: "Boolean"(optional, defaults to "false") If true, 1080 the organizer is expecting the participant to notify them of their 1081 status. 1083 o *scheduleSequence*: "Number"(optional, defaults to "0") The 1084 sequence number of the last response from the participant. If 1085 defined, this MUST be a non-negative integer. 1087 This can be used to determine whether the partcipant has sent a 1088 new RSVP following significant changes to the calendar object, and 1089 to determine if future responses are responding to a current or 1090 older view of the data. 1092 o *scheduleUpdated*: "UTCDate|null"(optional, defaults to "null") 1093 The *updated* property of the last iMIP response from the 1094 participant. 1096 This can be compared to the *updated* timestamp in future iMIP 1097 responses to determine if the response is older or newer than the 1098 current data. 1100 o *invitedBy*: "String|null"(optional, defaults to "null") The 1101 participant id of the participant who invited this one, if known. 1103 o *delegatedTo*: "String[]|null"(optional, defaults to "null") A 1104 list of participant ids of participants that this participant has 1105 delegated their participation to. This MUST be omitted if none 1106 (rather than an empty array). 1108 o *delegatedFrom*: "String[]|null"(optional, defaults to "null") A 1109 list of participant ids that this participant is acting as a 1110 delegate for. This MUST be omitted if none (rather than an empty 1111 array). 1113 o *memberOf*: "String[]|null"(optional, defaults to "null") A list 1114 of group participants that were invited to this calendar object, 1115 which caused this participant to be invited due to their 1116 membership of the group(s). This MUST be omitted if none (rather 1117 than an empty array). 1119 o *linkIds*: "String[]|null"(optional, defaults to "null") Links to 1120 more information about this participant, for example in vCard 1121 format. If a given value does not correspond to any link id in 1122 the links property of the instance, this id MUST be ignored. This 1123 MUST be omitted if none (rather than an empty array). 1125 4.5. Alerts properties 1127 4.5.1. useDefaultAlerts 1129 Type: "Boolean" (defaults to "false" if omitted) 1131 If "true", use the user's default alerts and ignore the value of the 1132 *alerts* property. Fetching user defaults is dependent on the API 1133 from which this JSCalendar object is being fetched, and is not 1134 defined in this specification. If an implementation cannot determine 1135 the user's default alerts, or none are set, it MUST process the 1136 alerts property as if useDefaultAlerts is set to "false". 1138 4.5.2. alerts 1140 Type: "String[Alert]|null" 1142 A map of alert ids to Alert objects, representing alerts/reminders to 1143 display or send the user for this calendar object. An alert id may 1144 be any string and need only be unique to this calendar object, 1145 although a globally unique id is a practical choice (also see 1146 Section 4.1.2)). 1148 An *Alert* Object has the following properties: 1150 o *relativeTo*: "String" (optional, defaults to "before-start") 1151 Specifies where the offset is relative to for the alarm to 1152 trigger. The value MUST be one of: 1154 * "before-start" 1156 * "after-start" 1158 * "before-end" 1160 * "after-end" 1162 o *offset*: "Duration" The offset from the start and end/due of the 1163 calendar object to fire the alert. If the calendar object does 1164 not define a time-zone, the user's default time-zone SHOULD be 1165 used when determining the offset, if known. Otherwise, the time- 1166 zone to use is implementation specific. 1168 o *action*: "DisplayAction|EmailAction|UnknownAction" 1170 Describes how to alert the user. 1172 A *DisplayAction* means a message (which is service dependent, but 1173 SHOULD include the title and start or due time of the calendar 1174 object) SHOULD be shown to the user on any client connected to 1175 this account at the specified time. How this message is formatted 1176 (and any sound or other method of drawing the user's attention) is 1177 client specific. It has the following properties: 1179 * *type*: "String" The value MUST be "display". 1181 * *acknowledged*: "UTCDate|null " (optional) 1183 When the user has permanently dismissed the alert the client 1184 MUST set this to the current time in UTC. Other clients which 1185 sync this property can then automatically dismiss or suppress 1186 duplicate alerts (alerts with the same alert id that triggered 1187 on or before this date-time). 1189 For a recurring calendar object, the *acknowledged* property of 1190 the parent object MUST be updated, unless the alert is already 1191 overridden in *recurrenceOverrides*. 1193 * *snoozed*: "UTCDate|null" (optional) 1195 If the user temporarily dismisses the alert, this is the UTC 1196 date-time after which it should be reshown. Clients displaying 1197 this alert SHOULD hide it if the snoozed property is updated to 1198 a time in the future. When that time is reached, the alert 1199 SHOULD be reshown unless acknowledged is now after the original 1200 trigger time. 1202 Setting this property on an instance of a recurring calendar 1203 object MUST update the alarm on the master object, unless the 1204 respective instance already is defined in 1205 "recurrenceOverrides". It MUST NOT generate an override for 1206 the sole use of snoozing an alarm. 1208 * *mediaLinkIds*: "String[]|null " (optional) 1210 A list of link identifiers in the JSCalendar object *links* 1211 property. Clients SHOULD play one or more of the link contents 1212 that are supported by the client implementation and are 1213 appropriate for the given device and user context. 1215 An *EmailAction* means an email SHOULD be sent as specified in the 1216 object at the specified time. It has the following properties: 1218 * *type*: "String" The value MUST be "email". 1220 * *to*: "Emailer[]" An array of name/email objects to send the 1221 alert to. 1223 An *Emailer* object has the following properties: 1225 + name: String The name of the recipient. If not known, 1226 clients SHOULD use the empty string. 1228 + email: String The email address of the recipient. 1230 * *subject*: "String" (optional) The subject to use for the 1231 email. If omitted, this is implementation specific, but the 1232 server SHOULD try to choose an appropriate subject, e.g. by 1233 including the summary. 1235 * *textBody*: "String" (optional) The plain-text body to use for 1236 the email. If omitted, the body of the email is implementation 1237 specific, but the server SHOULD include all pertinent details 1238 about the calendar object, such as summary, location and start 1239 time. 1241 * *htmlBody*: "String" (optional) The HTML body to use for the 1242 email, with rich-media content processed as for the 1243 *htmlDescription* property of the JSCalendar object (see 1244 Section 4.2.3). If the textBody property of this alert action 1245 is not set, the server SHOULD generate a plain-text version 1246 from the HTML body and include it in a "multipart/alternative" 1247 MIME message. 1249 An *UnknownAction* object is an object that contains a *type * 1250 property whose value is not "email" or "string", plus zero or more 1251 other properties. This is for compatibility with client 1252 extensions and future RFCs. The client or server SHOULD NOT 1253 trigger any type of alert for action types they do not understand, 1254 but MUST preserve them. 1256 4.6. Multilingual properties 1258 4.6.1. localizations 1260 Type: "String[PatchObject]|null" 1262 A map of [RFC5646] language tags to patch objects, which localise the 1263 calendar object into the locale of the respective language tag. 1265 See the description of PatchObject (Section 3.2.4) for the structure 1266 of the PatchObject. The patches are applied to the top-level object 1267 and MUST only patch the following properties: 1269 o title 1271 o description 1273 o htmlDescription 1275 o keywords 1277 o Location name 1279 o Location description 1281 o Link title 1282 o EmailAction alert subject 1284 o EmailAction alert textBody 1286 o EmailAction alert htmlBody 1288 o any Link properties entry except the "display" field 1290 o any UnknownAction alert property except the "type" field 1292 o any unknown or vendor-specific property (if not defined otherwise 1293 in a future RFC or vendor-specific extension). 1295 5. Type-specific JSCalendar properties 1297 5.1. JSEvent properties 1299 In addition to the common JSCalendar object properties (Section 4) a 1300 JSEvent has the following properties: 1302 5.1.1. start 1304 Type: "LocalDate" e.g. "2015-09-02T00:00:00" 1306 The date/time the event would start in the event's time-zone. 1308 A valid JSEvent MUST include this property. 1310 5.1.2. timeZone 1312 Type: "String|null" 1314 The IANA Time Zone Database [4] name for the time-zone the event is 1315 scheduled in, or "null" for floating time. If omitted, this MUST be 1316 presumed to be "null" (i.e. floating time). 1318 5.1.3. duration 1320 Type: "Duration", e.g. "P2DT3H" (Defaults to "P0D" if omitted) 1322 The zero or positive duration of the event in absolute time (i.e. in 1323 UTC time; ignoring DST shifts). To get the end date in the event 1324 time-zone, convert start into UTC, then add the duration, then 1325 convert the result into the appropriate time-zone. 1327 A JSEvent MAY be end in a different time-zone (e.g. a plane flight 1328 crossing time-zones). In this case, the JSEvent MUST specify the end 1329 time-zone in a *location* property value that defines its *rel* to be 1330 "end" and the end time-zone in its *timeZone* property. 1332 5.1.4. isAllDay 1334 Type: "Boolean" (optional, defaults to "false") 1336 Specifies if the event an all day event, such as a birthday or public 1337 holiday. 1339 If *isAllDay* is true, then the following restrictions apply: 1341 o the *start* property MUST have a time component of "T00:00:00". 1343 o the *duration* property MUST only include a day component. 1345 Note that all-day events MAY be bound to a specific time-zone, as 1346 defined by the *timeZone* property. 1348 5.1.5. status 1350 Type: "String" 1352 The scheduling status (Section 4.4) of a JSEvent defaults to 1353 "confirmed" if omitted. 1355 If set, it MUST be one of: 1357 o "confirmed": Indicates the event is definite. 1359 o "cancelled": Indicates the event is cancelled. 1361 o "tentative": Indicates the event is tentative. 1363 5.2. JSTask properties 1365 In addition to the common JSCalendar object properties (Section 4) a 1366 JSTask has the following properties: 1368 5.2.1. due 1370 Type: "LocalDate|null" e.g. "2015-09-02T00:00:00" 1372 The date/time the task is due in the task's time-zone. 1374 5.2.2. start 1376 Type: "LocalDate|null" e.g. "2015-09-02T00:00:00" 1378 The date/time the task should start in the task's time-zone. 1380 5.2.3. timeZone 1382 Type: "String|null" 1384 The IANA Time Zone Database name for the time-zone the task is 1385 scheduled in, or "null" for floating time. If omitted, this MUST be 1386 presumed to be "null" (i.e. floating time). 1388 5.2.4. estimatedDuration 1390 Type: "Duration|null", e.g. "P2DT3H" 1392 Specifies the estimated positive duration of time the task takes to 1393 complete. 1395 If the *start* and *due* properties are set, the estimated duration 1396 SHOULD be less than or equal to the time interval between these 1397 properties. 1399 5.2.5. completed 1401 Type: "UTCDate|null", e.g. "2016-06-13T12:00:00Z" 1403 Specifies the date/time the task was completed. 1405 If the task is recurring and has future instances, a client may want 1406 to denote a specific task recurrence as completed but leave other 1407 instances as uncompleted. One way to achieve this is by overriding 1408 the completed property in the task *recurrenceOverrides*. However, 1409 this could produce a long list of completion times for regularly 1410 recurring tasks. An alternative approach is to split the JSTask into 1411 a current, single instance of JSTask with this instance completion 1412 time and a future recurring instance. Also see the definition of the 1413 *relatedTo* on splitting. 1415 5.2.6. isAllDay 1417 Type: "Boolean" (optional, defaults to "false") 1419 Specifies if the task is an all day task. 1421 If *isAllDay* is true, then the following restrictions apply: 1423 o the *start* and *due* properties MUST have a time component of 1424 "T00:00:00". 1426 o the *estimatedDuration* property MUST only include a day 1427 component. 1429 Note that all-day tasks MAY be bound to a specific time-zone, as 1430 defined by the *timeZone* property. 1432 5.2.7. progress 1434 In addition to the common properties of a *Participant* object 1435 (Section 4.4.5), a Participant within a JSTask supports the following 1436 property: 1438 o *progress*: "ParticipantProgress|null" The progress of the 1439 participant for this task, if known. 1441 A *ParticipantProgress* object has the following properties: 1443 o *status*: "String" Describes the completion status of the 1444 participant's progress. 1446 The value MUST be at most one of the following values, registered 1447 in a future RFC, or a vendor-specific value: 1449 * "completed": The progress of this participant is complete. 1451 * "in-process": The progress of this participant is in process. 1453 o *timestamp*: "UTCDate" Describes the latest time when the 1454 participant progress got updated. 1456 5.2.8. status 1458 Type: "String" 1460 The scheduling status (Section 4.4) of a JSTask defaults to "needs- 1461 action" if omitted. 1463 If set, it MUST be one of: 1465 o "needs-action": Indicates the task needs action. 1467 o "completed": Indicates the task is completed. If this value is 1468 set, then the timestamp in the *completed* property MUST NOT be 1469 null. 1471 o "in-process": Indicates the task is in process. 1473 o "cancelled": Indicates the task is cancelled. 1475 5.3. JSGroup properties 1477 JSGroup supports the following JSCalendar properties (Section 4): 1479 o @type 1481 o uid 1483 o created 1485 o updated 1487 o categories 1489 o keywords 1491 o name 1493 o description 1495 o htmlDescription 1497 o color 1499 o links 1501 as well as the following JSGroup-specific properties: 1503 5.3.1. entries 1505 Type: "(JSTask|JSEvent)[]|null" 1507 A list of group members. The list MAY contain multiple object types 1508 and implementations MUST ignore entries of unknown type. The 1509 property value MUST either be "null" or the list MUST NOT be empty. 1511 5.3.2. source 1513 Type: "String|null" (optional, default is "null") 1515 The source from which updated versions of this group may be retrieved 1516 from. If the value is not "null", it MUST be a URI. 1518 6. Conversion from and to iCalendar 1520 This section specifies which JSCalendar properties can be mapped from 1521 and to iCalendar format. Implementations SHOULD follow these 1522 conversion guidelines. Still, JSCalendar does not restrict itself to 1523 iCalendar and conversion between these two formats MAY be lossy. 1525 6.1. JSEvent 1527 The iCalendar counterpart to *JSEvent* is the VEVENT component type 1528 [RFC5545]. A VEVENT component that is a direct child of a VCALENDAR 1529 component is equivalent to a standalone JSEvent. A VEVENT component 1530 *within* a VEVENT maps to the entries of the JSEvent 1531 *recurrenceOverrides* property. 1533 +----------+--------------------------------------------------------+ 1534 | Property | iCalendar counterpart | 1535 +----------+--------------------------------------------------------+ 1536 | isAllDay | True, if the type of the DTSTART property in iCalendar | 1537 | | is DATE. When translating from JSCalendar the | 1538 | | iCalendar DTSTART property is of DATE value type, if | 1539 | | the *isAllDay* property is set to true and the | 1540 | | *timeZone* property is null. | 1541 | | | 1542 | start | Corresponds to the DTSTART property in iCalendar. Note | 1543 | | that time-zone information is stored separately in | 1544 | | JSEvent. | 1545 | | | 1546 | timeZone | Corresponds to the TZID part of the DTSTART property | 1547 | | in iCalendar. If the event has a different end time- | 1548 | | zone to start time-zone, this should be added as a | 1549 | | JSCalendar *location* with just a *timeZone* property | 1550 | | and "rel="end"". | 1551 | | | 1552 | duration | Corresponds to the DURATION or DSTART+DTEND properties | 1553 | | in iCalendar. | 1554 +----------+--------------------------------------------------------+ 1556 Table 2: Translation between JSEvent and iCalendar 1558 6.2. JSTask 1560 The iCalendar counterpart to *JSTask* is the VTODO component type 1561 [RFC5545]. A VTODO component that is a direct child of a VCALENDAR 1562 component is equivalent to a standalone JSTask. A VTODO component 1563 *within* a master VTODO maps to the entries of the JSTask 1564 *recurrenceOverrides* property. 1566 +-------------------+-----------------------------------------------+ 1567 | Property | iCalendar counterpart | 1568 +-------------------+-----------------------------------------------+ 1569 | isAllDay | True, if the type of the DTSTART property in | 1570 | | iCalendar is DATE. When translating from | 1571 | | JSCalendar the iCalendar DTSTART property is | 1572 | | of DATE value type, if the *isAllDay* | 1573 | | property is set to true and the *timeZone* | 1574 | | property is null. | 1575 | | | 1576 | due | Corresponds to the DUE and DTSTART+DURATION | 1577 | | properties in iCalendar. When mapping | 1578 | | iCalendar VTODOs with DTSTART+DURATION, the | 1579 | | due date is the result of adding DURATION to | 1580 | | DTSTART in the DTSTART time-zone. | 1581 | | | 1582 | start | Corresponds to the DTSTART property in | 1583 | | iCalendar. | 1584 | | | 1585 | timeZone | Corresponds to the TZID part of the | 1586 | | DTSTART/DUE properties in iCalendar. If the | 1587 | | task has a different end time-zone to start | 1588 | | or due time-zone, this should be added as a | 1589 | | JSCalendar *location* with just a *timeZone* | 1590 | | property and "rel="end"". | 1591 | | | 1592 | estimatedDuration | Corresponds to the ESTIMATED-DURATION | 1593 | | iCalendar property. *NON-STANDARD*: this | 1594 | | property is currently non-standard, see | 1595 | | [draft-apthorp-ical-tasks]. | 1596 | | | 1597 | completed | Maps to the COMPLETED iCalendar property. | 1598 | | | 1599 | progress | Corresponds to the PARTSTAT and COMPLETED | 1600 | | properties in iCalendar. | 1601 +-------------------+-----------------------------------------------+ 1603 Table 3: Translation between JSTask and iCalendar 1605 6.3. JSGroup 1607 A JSGroup converts to a iCalendar VCALENDAR containing VEVENT or 1608 VTODO components. 1610 +----------+--------------------------------------------------------+ 1611 | Property | iCalendar counterpart | 1612 +----------+--------------------------------------------------------+ 1613 | entries | The VEVENT and VTODO components within a top-level | 1614 | | VCALENDAR component. | 1615 | | | 1616 | source | Corresponds to the SOURCE property in iCalendar. | 1617 +----------+--------------------------------------------------------+ 1619 Table 4: Translation between JSGroup and iCalendar 1621 6.4. Common properties 1623 +---------------------+---------------------------------------------+ 1624 | Property | iCalendar counterpart | 1625 +---------------------+---------------------------------------------+ 1626 | alerts | An *Alert* corresponds to the VALARM | 1627 | | component in iCalendar, where the *action* | 1628 | | is determined by the iCalendar ACTION | 1629 | | property value (e.g., a "DISPLAY" property | 1630 | | indicates that the JSCalendar Alert action | 1631 | | is a *DisplayAction* and similarly an | 1632 | | iCalendar "EMAIL" value for *EmailAction* | 1633 | | action). The *relativeTo* and *offset* | 1634 | | properties corresponds to the iCalendar | 1635 | | TRIGGER property. *NON-STANDARD*: The | 1636 | | iCalendar properties for JSCalendar Alert | 1637 | | actions are non-standard, see | 1638 | | [draft-daboo-valarm-extensions]. | 1639 | | | 1640 | categories | Corresponds to the STRUCTURED-CATEGORY | 1641 | | property in iCalendar, see. *NON- | 1642 | | STANDARD*: this property is currently non- | 1643 | | standard, see | 1644 | | [draft-ietf-calext-ical-relations]. | 1645 | | | 1646 | color | Corresponds to the COLOR property in | 1647 | | iCalendar, as specified in [RFC7986]. | 1648 | | | 1649 | created | Corresponds to the CREATED property in | 1650 | | iCalendar. | 1651 | | | 1652 | description | Corresponds to the DESCRIPTION property in | 1653 | | iCalendar. | 1654 | | | 1655 | htmlDescription | There is no direct equivalent in iCalendar. | 1656 | | If the *description* is empty, | 1657 | | implementations SHOUD store a plain text | 1658 | | version of *htmlDescription* in iCalendar | 1659 | | DESCRIPTION. | 1660 | | | 1661 | freeBusyStatus | Corresponds to the TRANSP property in | 1662 | | iCalendar. | 1663 | | | 1664 | keywords | Corresponds to the CATEGORIES property in | 1665 | | iCalendar, as specified in [RFC7986]. | 1666 | | | 1667 | links | Corresponds to the ATTACH ([RFC5545]) and | 1668 | | IMAGE iCalendar properties ([RFC7986]). | 1669 | | | 1670 | locale | Corresponds to the LANGUAGE parameter in | 1671 | | iCalendar, which is added to individual | 1672 | | properties. When converting from | 1673 | | iCalendar, one language must be picked as | 1674 | | the main locale for the object, and all | 1675 | | properties in other languages moved to the | 1676 | | localizations JSEvent property. | 1677 | | | 1678 | localizations | Corresponds to the LANGUAGE parameter in | 1679 | | iCalendar, which is added to individual | 1680 | | properties. When converting from | 1681 | | iCalendar, one language must be picked as | 1682 | | the main locale for the object, and all | 1683 | | properties in other languages moved to the | 1684 | | localizations JSEvent property. | 1685 | | | 1686 | locations | See Section 6.5. | 1687 | | | 1688 | method | Corresponds to the METHOD property in | 1689 | | iCalendar. | 1690 | | | 1691 | participants | See Section 6.5. | 1692 | | | 1693 | priority | Corresponds to the PRIORITY property in | 1694 | | iCalendar. | 1695 | | | 1696 | privacy | Corresponds to the CLASS property in | 1697 | | iCalendar. | 1698 | | | 1699 | prodId | Corresponds to the PRODID property in | 1700 | | iCalendar. | 1701 | | | 1702 | recurrenceOverrides | Corresponds to the RDATE and EXDATE | 1703 | | properties in iCalendar, plus VEVENT (for | 1704 | | JSEvent) or VTODO (for JSTask) instances | 1705 | | with a recurrence-id. | 1706 | | | 1707 | recurrenceRule | Corresponds to the RRULE property in | 1708 | | iCalendar. See the property definition at | 1709 | | section Section 4.3.1 how to map a RRULE | 1710 | | value. | 1711 | | | 1712 | relatedTo | Corresponds to the RELATED-TO property in | 1713 | | iCalendar. | 1714 | | | 1715 | replyTo | A *replyTo* property of type "imip" | 1716 | | corresponds to the email address of the | 1717 | | ORGANIZER property in iCalendar. There is | 1718 | | no iCalendar representation for the "web" | 1719 | | type. | 1720 | | | 1721 | sequence | Corresponds to the SEQUENCE property in | 1722 | | iCalendar. | 1723 | | | 1724 | status | Corresponds to the STATUS property in | 1725 | | iCalendar (converted to lower-case). | 1726 | | | 1727 | title | Corresponds to the SUMMARY property in | 1728 | | iCalendar. | 1729 | | | 1730 | uid | Corresponds to the UID property in | 1731 | | iCalendar. | 1732 | | | 1733 | updated | Corresponds to the DTSTAMP and LAST- | 1734 | | MODIFIED properties in iCalendar. (These | 1735 | | are only different in the iTIP case, and | 1736 | | the difference is not actually useful.) | 1737 +---------------------+---------------------------------------------+ 1739 Table 5: Translation between JSCalendar and iCalendar 1741 6.5. Locations and participants 1743 Both JSCalendar participants and locations have counterparts in 1744 iCalendar but provide richer representation. 1746 The following table outlines translation of JSCalendar participants. 1747 Where iCalendar has distinct properties for ORGANIZER and ATTENDEE, 1748 these are merged in JSCalendar into the Participant object type. 1750 +------------------+------------------------------------------------+ 1751 | Property | iCalendar counterpart | 1752 +------------------+------------------------------------------------+ 1753 | name | the CN parameter | 1754 | | | 1755 | kind | the CUTYPE parameter | 1756 | | | 1757 | rsvpResponse | the PARTSTAT parameter | 1758 | | | 1759 | role | the ORGANIZER and ATTENDEE properties. Owners | 1760 | | map to the iCalendar ORGANIZER property, where | 1761 | | mapping multiple owners to iCalendar is | 1762 | | implementation-specific but MUST be consistent | 1763 | | across mappings of the same object. | 1764 | | | 1765 | participation | the ROLE parameter | 1766 | | | 1767 | locationId | the JSCalendar identifier of a mapped | 1768 | | CONFERENCE property that has the MODERATOR | 1769 | | feature defined in its FEATURE parameter | 1770 | | values. If multiple such CONFERENCE properties | 1771 | | are defined in iCalendar, then the one with | 1772 | | the most interactive features is chosen (VIDEO | 1773 | | over AUDIO over CHAT over anything else). | 1774 | | | 1775 | rsvpWanted | the RSVP parameter | 1776 | | | 1777 | delegatedTo | the DELEGATED-TO parameter | 1778 | | | 1779 | delegatedFrom | the DELEGATED-FROM parameter | 1780 | | | 1781 | memberOf | the MEMBER parameter | 1782 | | | 1783 | scheduleSequence | the SEQUENCE property of the participant's | 1784 | | latest iMIP message | 1785 | | | 1786 | scheduleUpdated | the DTSTAMP property of the participant's | 1787 | | latest iMIP message | 1788 +------------------+------------------------------------------------+ 1790 Table 6: Translation of Participant between JSCalendar and iCalendar 1792 For JSCalendar locations, the iCalendar counterparts are the 1793 [RFC5545] LOCATION and the extended iCalendar [RFC7986] CONFERENCE 1794 properties. 1796 An iCalendar LOCATION property becomes a JSCalendar Location with 1797 just a description property. CONFERENCE property values in iCalendar 1798 map to locations with *rel* type "virtual". The location *feature* 1799 property value corresponds to the extended iCalendar FEATURE property 1800 parameter values defined in [RFC7986]. Both iCalendar PHONE and 1801 AUDIO features map to the "audio" feature and the FEED parameter 1802 value is omitted. See the mapping for *locationId* in Table 6 on how 1803 to map CONFERENCE properties that contain the MODERATOR feature. 1805 6.6. Unknown properties 1807 Both JSCalendar and iCalendar calendar objects may contain properties 1808 that are not expressible in the other format. This specification 1809 does not mandate how to preserve these properties. Instead, it 1810 leaves negotiation on how to treat unknown properties to client and 1811 server implementations and their protocol used to exchange calendar 1812 objects. 1814 Two notable options to represent and preserve arbitrary iCalendar 1815 object properties in JSCalendar are: 1817 o *JCal*: Define iCalendar properties in JCal format ([RFC7265]) in 1818 a vendor-specific property of the JCalendar object. The JCal- 1819 formatted value may either only contain iCalendar properties that 1820 were not mapped to JSCalendar properties, or contain the complete 1821 iCalendar object representation. 1823 o *Alternate link*: Define an alternate link (Section 4.2.5) value 1824 pointing to the iCalendar representation of the JSCalendar object. 1825 E.g. the alternative representation of a VEVENT would be 1826 represented as a link with rel "alternate" and type "text/ 1827 calendar;component=VEVENT". 1829 7. JSCalendar object examples 1831 The following examples illustrate several aspects of the JSCalendar 1832 data model and format. 1834 7.1. Simple JSEvent 1836 This JSEvent object represents a one-time event taking place on 1837 September 28 at 4pm, UTC for one hour. 1839 { 1840 "@type": "jsevent", 1841 "uid": "2a358cee-6489-4f14-a57f-c104db4dc357", 1842 "updated": "2016-09-14T13:24:34Z", 1843 "title": "Squash", 1844 "description": "", 1845 "htmlDescription": "", 1846 "start": "2016-09-28T16:00:00", 1847 "timeZone": "Etc/UTC", 1848 "duration": "PT1H", 1849 "recurrenceRule": null, 1850 "recurrenceOverrides": null, 1851 "freeBusyStatus": "free", 1852 "replyTo": null, 1853 "participants": null, 1854 "alerts": null, 1855 "links": null, 1856 "locations": null, 1857 "locale": "en", 1858 "localizations": null, 1859 } 1861 Since properties can be omitted if their default value is used, this 1862 can be simplified to: 1864 { 1865 "@type": "jsevent", 1866 "uid": "2a358cee-6489-4f14-a57f-c104db4dc357", 1867 "updated": "2016-09-14T13:24:34Z", 1868 "title": "Squash", 1869 "start": "2016-09-28T16:00:00", 1870 "timeZone": "Etc/UTC", 1871 "duration": "PT1H", 1872 "locale": "en" 1873 } 1875 7.2. Recurring JSEvent with exception 1877 This JSEvent object represents a recurring event, taking place the 1878 first time on January 1, 2016 at 1pm in Vienna, Europe. It recurs 1879 monthly, but does not occur on February 1, 2016. In addition to the 1880 regular recurrences it also occurs on December 5, 2016 at 5pm, Vienna 1881 time. On May 1, it takes place at another location and lasts for two 1882 hours, in contrast to the regular one-hour duration. 1884 { 1885 "@type": "jsevent", 1886 "uid": "89eee195-600b-423b-b3a6-52b3a420e556", 1887 "title": "Tennis", 1888 "locations": { 1889 "loc1" : { 1890 "description" : "Joe's Tennis Plaza, Court #1" 1891 } 1892 }, 1893 "isAllDay": false, 1894 "start": "2016-01-01T13:00:00", 1895 "timeZone": "Europe/Vienna", 1896 "duration": "PT1H", 1897 "recurrenceRule": { 1898 "frequency": "monthly", 1899 }, 1900 "recurrenceOverrides": { 1901 "2016-02-01T13:00:00": null, 1902 "2016-05-01T13:00:00": { 1903 "duration": "PT2H", 1904 "locations": { 1905 "loc2": { 1906 "description": "Tennis Fritz&Mayer, Ltd." 1907 } 1908 }, 1909 "2016-12-05T17:00:00": {}, 1910 } 1911 } 1912 } 1914 Note that the recurrenceOverride on May 1 overrides the complete 1915 location object. If the event should occur at *both* locations, the 1916 PatchObject would be defined as follows: 1918 { 1919 [...] 1920 "recurrenceOverrides": { 1921 [...] 1922 "2016-05-01T13:00:00": { 1923 "duration": "PT2H", 1924 "locations/loc2": { 1925 "description": "Tennis Fritz&Mayer, Ltd." 1926 } 1927 } 1928 } 1930 8. Security Considerations 1932 The use of JSON as a format does have its own inherent security risks 1933 as discussed in Section 12 of [RFC8259]. Even though JSON is 1934 considered a safe subset of JavaScript, it should be kept in mind 1935 that a flaw in the parser processing JSON could still impose a 1936 threat, which doesn't arise with conventional iCalendar data. 1938 With this in mind, a parser for JSON data aware of the security 1939 implications should be used for the format described in this 1940 document. For example, the use of JavaScript's "eval()" function is 1941 considered an unacceptable security risk, as described in Section 12 1942 of[RFC8259]. A native parser with full awareness of the JSON format 1943 should be preferred. 1945 9. IANA Considerations 1947 This document amends the "application/calendar" MIME media type 1948 defined in [RFC7265]. 1950 New optional parameter: "type" with value being one of "jsevent", 1951 "jstask", "jsgroup". The parameter MUST NOT occur more than once. 1953 10. Acknowledgments 1955 The authors would like to thank the members of CalConnect for their 1956 valuable contributions. This specification originated from the work 1957 of the API technical committee of CalConnect, the Calendaring and 1958 Scheduling Consortium. 1960 11. References 1962 11.1. Normative References 1964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1965 Requirement Levels", BCP 14, RFC 2119, 1966 DOI 10.17487/RFC2119, March 1997, 1967 . 1969 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1970 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 1971 . 1973 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1974 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1975 . 1977 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1978 Resource Identifier (URI): Generic Syntax", STD 66, 1979 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1980 . 1982 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1983 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1984 DOI 10.17487/RFC4122, July 2005, 1985 . 1987 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 1988 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 1989 DOI 10.17487/RFC4791, March 2007, 1990 . 1992 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1993 Scheduling Core Object Specification (iCalendar)", 1994 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1995 . 1997 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1998 Interoperability Protocol (iTIP)", RFC 5546, 1999 DOI 10.17487/RFC5546, December 2009, 2000 . 2002 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2003 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2004 September 2009, . 2006 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 2007 Identifier for Geographic Locations ('geo' URI)", 2008 RFC 5870, DOI 10.17487/RFC5870, June 2010, 2009 . 2011 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based 2012 Interoperability Protocol (iMIP)", RFC 6047, 2013 DOI 10.17487/RFC6047, December 2010, 2014 . 2016 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 2017 and D. Orchard, "URI Template", RFC 6570, 2018 DOI 10.17487/RFC6570, March 2012, 2019 . 2021 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2022 Specifications and Registration Procedures", BCP 13, 2023 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2024 . 2026 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 2027 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 2028 DOI 10.17487/RFC6901, April 2013, 2029 . 2031 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 2032 Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 2033 2014, . 2035 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 2036 DOI 10.17487/RFC7493, March 2015, 2037 . 2039 [RFC7529] Daboo, C. and G. Yakushev, "Non-Gregorian Recurrence Rules 2040 in the Internet Calendaring and Scheduling Core Object 2041 Specification (iCalendar)", RFC 7529, 2042 DOI 10.17487/RFC7529, May 2015, 2043 . 2045 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 2046 DOI 10.17487/RFC7986, October 2016, 2047 . 2049 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2050 Interchange Format", STD 90, RFC 8259, 2051 DOI 10.17487/RFC8259, December 2017, 2052 . 2054 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 2055 DOI 10.17487/RFC8288, October 2017, 2056 . 2058 11.2. Informative References 2060 [draft-apthorp-ical-tasks] 2061 "Task Extensions to iCalendar", 2062 . 2064 [draft-daboo-valarm-extensions] 2065 "VALARM Extensions for iCalendar", 2066 . 2069 [draft-ietf-calext-ical-relations] 2070 "Support for iCalendar Relationships", 2071 . 2074 11.3. URIs 2076 [1] https://www.w3.org/TR/html/ 2078 [2] https://www.iana.org/assignments/link-relations/link- 2079 relations.xhtml 2081 [3] https://www.w3.org/TR/2011/REC-css3-color-20110607/#svg-color 2083 [4] http://www.iana.org/time-zones 2085 Authors' Addresses 2087 Neil Jenkins 2088 FastMail 2089 PO Box 234 2090 Collins St West 2091 Melbourne VIC 8007 2092 Australia 2094 Email: neilj@fastmailteam.com 2095 URI: https://www.fastmail.com 2097 Robert Stepanek 2098 FastMail 2099 PO Box 234 2100 Collins St West 2101 Melbourne VIC 8007 2102 Australia 2104 Email: rsto@fastmailteam.com 2105 URI: https://www.fastmail.com