idnits 2.17.1 draft-ietf-jcardcal-jcal-10.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 26, 2014) is 3655 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JSON data formats for vCard and iCalendar P. Kewisch 3 Internet-Draft Mozilla 4 Intended status: Standards Track C. Daboo 5 Expires: September 27, 2014 Apple, Inc. 6 M. Douglass 7 RPI 8 March 26, 2014 10 jCal: The JSON format for iCalendar 11 draft-ietf-jcardcal-jcal-10 13 Abstract 15 This specification defines "jCal", a JSON format for iCalendar data. 16 The iCalendar data format is a text format for capturing and 17 exchanging information normally stored within a calendaring and 18 scheduling application, for example tasks and events. JSON is a 19 lightweight, text-based, language-independent data interchange format 20 commonly used in internet applications. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 27, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 58 3. Converting from iCalendar to jCal . . . . . . . . . . . . . . 4 59 3.1. Pre-processing . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. iCalendar Stream and Objects (RFC5545 section 3.4) . . . 5 61 3.3. Components (RFC5545 section 3.6) . . . . . . . . . . . . 6 62 3.4. Properties (RFC5545 section 3.7 and 3.8) . . . . . . . . 6 63 3.4.1. Special Cases for Properties . . . . . . . . . . . . 8 64 3.4.1.1. GEO Property (RFC5545 Section 3.8.1.6) . . . . . 8 65 3.4.1.2. REQUEST-STATUS Property (RFC5545 Section 3.8.8.3) 8 66 3.5. Parameters (RFC5545 section 3.2) . . . . . . . . . . . . 9 67 3.5.1. VALUE parameter . . . . . . . . . . . . . . . . . . . 10 68 3.5.2. Multi-value Parameters . . . . . . . . . . . . . . . 11 69 3.6. Values (RFC5545 section 3.3) . . . . . . . . . . . . . . 11 70 3.6.1. Binary (RFC5545 section 3.3.1) . . . . . . . . . . . 12 71 3.6.2. Boolean (RFC5545 section 3.3.2) . . . . . . . . . . 12 72 3.6.3. Calendar User Address (RFC5545 section 3.3.3) . . . . 12 73 3.6.4. Date (RFC5545 section 3.3.4) . . . . . . . . . . . . 12 74 3.6.5. Date-Time (RFC5545 section 3.3.5) . . . . . . . . . . 13 75 3.6.6. Duration (RFC5545 section 3.3.6) . . . . . . . . . . 13 76 3.6.7. Float (RFC5545 section 3.3.7) . . . . . . . . . . . . 14 77 3.6.8. Integer (RFC5545 section 3.3.8) . . . . . . . . . . . 14 78 3.6.9. Period of Time (RFC5545 section 3.3.9) . . . . . . . 14 79 3.6.10. Recurrence Rule (RFC5545 section 3.3.10) . . . . . . 15 80 3.6.11. Text (RFC5545 section 3.3.11) . . . . . . . . . . . . 16 81 3.6.12. Time (RFC5545 section 3.3.12) . . . . . . . . . . . . 16 82 3.6.13. URI (RFC5545 section 3.3.13) . . . . . . . . . . . . 17 83 3.6.14. UTC Offset (RFC5545 section 3.3.14) . . . . . . . . . 17 84 3.7. Extensions . . . . . . . . . . . . . . . . . . . . . . . 17 85 4. Converting from jCal into iCalendar . . . . . . . . . . . . . 18 86 5. Handling Unrecognized Properties or Parameters . . . . . . . 18 87 5.1. Converting iCalendar into jCal . . . . . . . . . . . . . 19 88 5.2. Converting jCal into iCalendar . . . . . . . . . . . . . 19 89 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 7.1. UNKNOWN iCalendar Value Data Type . . . . . . . . . . . . 23 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 96 9.2. Informative References . . . . . . . . . . . . . . . . . 24 98 Appendix A. Implementation Status (to be removed prior to 99 publication as an RFC, as well as the reference to 100 RFC6982) . . . . . . . . . . . . . . . . . . . . . . 24 101 Appendix B. ABNF Schema . . . . . . . . . . . . . . . . . . . . 26 102 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 27 103 C.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 27 104 C.1.1. iCalendar Data . . . . . . . . . . . . . . . . . . . 27 105 C.1.2. jCal Data . . . . . . . . . . . . . . . . . . . . . . 28 106 C.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 28 107 C.2.1. iCalendar Data . . . . . . . . . . . . . . . . . . . 28 108 C.2.2. jCal Data . . . . . . . . . . . . . . . . . . . . . . 29 109 Appendix D. Change History (to be removed prior to publication 110 as an RFC) . . . . . . . . . . . . . . . . . . . . . 31 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 113 1. Introduction 115 The iCalendar data format [RFC5545] is a widely deployed interchange 116 format for calendaring and scheduling data. While many applications 117 and services consume and generate calendar data, iCalendar is a 118 specialized format that requires its own parser/generator. In 119 contrast, JSON-based formats as defined in [RFC7159] are the native 120 format for JavaScript widgets and libraries and it is appropriate to 121 have a standard form of calendar data that is easier to work with 122 than iCalendar. 124 The purpose of this specification is to define "jCal", a JSON format 125 for iCalendar data. jCal is defined as a straightforward mapping 126 into JSON from iCalendar, so that iCalendar data can be converted to 127 JSON, and then back to iCalendar, without losing any semantic meaning 128 in the data. Anyone creating jCal calendar data according to this 129 specification will know that their data can be converted to a valid 130 iCalendar representation as well. 132 The key design considerations are essentially the same as those for 133 [RFC6321], that is: 135 Round-tripping (converting an iCalendar instance to jCal and back) 136 will give the same semantic result as the starting point. For 137 example, all components, properties and property parameters are 138 guaranteed to be preserved. 140 Ordering of elements and case of property and parameter names will 141 not necessarily be preserved. 143 The iCalendar data semantics are to be preserved, allowing a 144 simple consumer to easily browse the data in jCal. A full 145 understanding of iCalendar is still required in order to modify 146 and/or fully comprehend the calendar data. 148 Extensions to the underlying iCalendar specification must not lead 149 to requiring an update to jCal. 151 2. Conventions Used in This Document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 The underlying format used for jCal is JSON. Consequently, the terms 158 "object" and "array" as well as the four primitive types (strings, 159 numbers, booleans, and null) are to be interpreted as described in 160 Section 1 of [RFC7159]. 162 Some examples in this document contain "partial" JSON documents used 163 for illustrative purposes. In these examples, three periods "..." 164 are used to indicate a portion of the document that has been removed 165 for compactness. 167 3. Converting from iCalendar to jCal 169 This section describes how iCalendar data is converted to jCal using 170 a simple mapping between the iCalendar data model and JSON elements. 171 Aside from the formal description in this section, an informative 172 ABNF is specified in Appendix B. 174 In [RFC5545], an iCalendar object comprises a set of "components", 175 "properties", "parameters" and "values". The top level of iCalendar 176 data typically contains a stream of iCalendar objects, each of which 177 can be considered a "component". A "component" can contain other 178 "components" or "properties". A "property" has a "value" and a set 179 of zero or more "parameters". Each of these entities have a 180 representation in jCal, defined in the following sections. The 181 representation of a iCalendar object in JSON will be named "jCal 182 object" throughout this document. 184 3.1. Pre-processing 186 iCalendar uses a line folding mechanism to limit lines of data to a 187 maximum line length (typically 75 octets) to ensure maximum 188 likelihood of preserving data integrity as it is transported via 189 various means (e.g., email) - see Section 3.1 of [RFC5545]. 191 iCalendar data uses an "escape" character sequence for text values 192 and property parameter values. See Section 3.1 and 3.3 of [RFC5545] 193 as well as [RFC6868]. 195 There is a subtle difference in the number representations between 196 JSON and iCalendar. While in iCalendar a number may have leading 197 zeros, as well as a leading plus sign, this is not the case in JSON. 198 Numbers should be represented in whatever way needed for the 199 underlying format. 201 When converting from iCalendar to jCal, first iCalendar lines MUST be 202 unfolded. Afterwards, any iCalendar escaping MUST be unescaped. 203 Finally JSON escaping, as described in [RFC7159] Section 7, MUST be 204 applied. The reverse order applies when converting from jCal to 205 iCalendar, which is further described in Section 4. 207 iCalendar uses a base64 encoding for binary data. However, it does 208 not restrict the encoding from being applied to non-binary value 209 types. So the following rules are applied when processing a property 210 with the "ENCODING" property parameter set to "BASE64": 212 o If the property value type is "BINARY", the base64 encoding MUST 213 be preserved. 215 o If the value type is not "BINARY", the "ENCODING" property 216 parameter MUST be removed, and the value MUST be base64 decoded. 218 When base64 encoding and decoding is used, it MUST conform to 219 Section 4 of [RFC4648], which is the base64 method used in [RFC5545]. 221 One key difference in the formatting of values used in iCalendar and 222 jCal is that in jCal the specification uses date/time values aligned 223 with the extended format of [ISO.8601.2004], which is more commonly 224 used in internet applications that make use of the JSON format. The 225 sections of this document describing the various date and time 226 formats contain more information on the use of the complete 227 representation, reduced accuracy or truncated representation. 229 3.2. iCalendar Stream and Objects (RFC5545 section 3.4) 231 At the top level of the iCalendar object model is an "iCalendar 232 stream". This stream encompasses multiple "iCalendar objects". As 233 the typical use case is transporting a single iCalendar object, there 234 is no defined equivalent to an "iCalendar stream" in jCal. To 235 transport multiple jCal objects in a stream, a simple JSON array can 236 be used. 238 Example: 240 ["vcalendar", 241 [ /* Add jCal properties in place of this comment */ ], 242 [ /* Add jCal components in place of this comment */ ] 243 ] 245 3.3. Components (RFC5545 section 3.6) 247 Each iCalendar component, delimited by "BEGIN" and "END", will be 248 converted to a fixed length array with three fields that have a 249 specific structure: 251 1. A string with the name of the iCalendar component, but in 252 lowercase. 254 2. An array of jCal properties as described in Section 3.4. 256 3. An array of jCal components, representing the sub-components of 257 the component in question. 259 This mapping applies to the top level iCalendar objects, as well as 260 individual sub-components in the same way. The iCalendar to jCal 261 component mapping is valid for both current iCalendar components and 262 any new iCalendar components added in the future. Conversion is to 263 be done in the same way. 265 While the grouping of properties and sub-components does not retain 266 the original order specified in the iCalendar data, the semantics of 267 a component are preserved. 269 Example: 271 ["vevent", 272 [ /* Add jCal properties in place of this comment */ ], 273 [ /* Add jCal components in place of this comment */ ] 274 ] 276 3.4. Properties (RFC5545 section 3.7 and 3.8) 278 iCalendar properties, whether they apply to the "VCALENDAR" object or 279 to a component, are handled in a consistent way in the jCal format. 281 In jCal, each individual iCalendar property MUST be represented by an 282 array with three fixed elements, followed by one or more additional 283 elements, depending on if the property is a multi-value property as 284 described in Section 3.1.2 of [RFC5545]. 286 The array consists of the following fixed elements: 288 1. The name of the property, as a lowercase string. The iCalendar 289 format specifies that property names are case-insensitive, and 290 recommends that they be rendered in uppercase. In jCal, they 291 MUST be in lowercase. 293 2. An object containing the parameters as described in Section 3.5. 294 If the property has no parameters, an empty object is used to 295 represent that. 297 3. The type identifier string of the value, in lowercase. Due to 298 special casing of certain properties as described in 299 Section 3.4.1, it is important that parsers check both the type 300 identifier and the value data type and do not rely on assumptions 301 based on the property name. 303 The remaining elements of the array are used for one or more values 304 of the property. For single-value properties, the array has exactly 305 four elements; for multi-valued properties, as described in [RFC5545] 306 Section 3.1.2, each value is another element, and there can be any 307 number of additional elements. 309 In the following example, the "categories" property is multi-valued 310 and has two values, while the summary property is single-valued: 312 Example: 314 ["vevent", 315 [ 316 ["summary", {}, "text", "Meeting with Fred"], 317 ["categories", {}, "text", "Meetings", "Work"] 318 ... 319 ], 320 [ /* sub-components */ ] 321 ] 323 3.4.1. Special Cases for Properties 325 This section describes some properties that have special handling 326 when converting to jCal. 328 3.4.1.1. GEO Property (RFC5545 Section 3.8.1.6) 330 In iCalendar, the "GEO" property value is defined as a semi-colon 331 separated list of two "FLOAT" values, the first representing latitude 332 and the second longitude. 334 In jCal, the value for the "geo" property value is represented as an 335 array of two values. The first value of the property represents the 336 latitude, the second value represents the longitude. 338 When converting from jCal to iCalendar, be careful to use a semi- 339 colon as the separator between the two values as required by RFC5545. 341 When converting from jCal to iCalendar, the two values MUST be 342 converted using a semi-colon as the separator character. 344 Example 346 ["vevent", 347 [ 348 ["geo", {}, "float", [ 37.386013, -122.082932 ] ] 349 ... 350 ], 351 ... 352 ] 354 3.4.1.2. REQUEST-STATUS Property (RFC5545 Section 3.8.8.3) 356 In iCalendar, the "REQUEST-STATUS" property value is defined as a 357 semi-colon separated list of two or three "TEXT" values. The first 358 represents a code, the second a description, and the third any 359 additional data. 361 In jCal, the value for the "request-status" property value is 362 represented as an array with two or three values. The first array 363 element corresponds to the code, the second element corresponds to 364 the description and the third element corresponds to the additional 365 data. Each value is represented using a string value. If there is 366 no additional data in the iCalendar value, the last element of the 367 array SHOULD NOT be present. 369 When converting from jCal to iCalendar, the two or three values MUST 370 be converted using a semi-colon as the separator character. 372 iCalendar Example: 374 BEGIN:VEVENT 375 ... 376 REQUEST-STATUS:2.0;Success 377 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: 378 mailto:jsmith@example.com 379 ... 380 END:VEVENT 382 jCal Example: 384 ["vevent": 385 [ 386 ["request-status", {}, "text", ["2.0", "Success"] ], 387 ["request-status", {}, "text", 388 [ 389 "3.7", 390 "Invalid calendar user", 391 "ATTENDEE:mailto:jsmith@example.org" 392 ] 393 ], 394 ... 395 ], 396 ... 397 ] 399 3.5. Parameters (RFC5545 section 3.2) 401 Property parameters are represented as a JSON object where each key- 402 value pair represents the iCalendar parameter name and its value. 403 The name of the parameter MUST be in lowercase, the original case of 404 the parameter value MUST be preserved. For example, the "PARTSTAT" 405 property parameter is represented in jCal by the "partstat" key. Any 406 new iCalendar parameters added in the future will be converted in the 407 same way. 409 Example: 411 ["vevent": 412 [ 413 ["attendee", 414 { 415 "partstat": "ACCEPTED", 416 "rsvp": "TRUE", 417 "role": "REQ-PARTICIPANT" 418 }, 419 "cal-address", 420 "mailto:jsmith@example.org" 421 ], 422 ["summary", {}, "text", "Meeting"], 423 ... 424 ], 425 ... 426 ] 428 3.5.1. VALUE parameter 430 iCalendar defines a "VALUE" property parameter (Section 3.2.20 of 431 [RFC5545]). This property parameter MUST NOT be added to the 432 parameters object. Instead, the value type is signaled through the 433 type identifier in the third element of the array describing the 434 property. When converting a property from iCalendar to jCal, the 435 value type is determined as follows: 437 1. If the property has a "VALUE" parameter, that parameter's value 438 is used as the value type. 440 2. If the property has no "VALUE" parameter but has a default value 441 type, the default value type is used. 443 3. If the property has no "VALUE" parameter and has no default value 444 type, "unknown" is used. 446 Converting from jCal into iCalendar is done as follows: 448 1. If the property's value type is "unknown", no "VALUE" parameter 449 is included. 451 2. If the property's value type is the default type for that 452 property, no "VALUE" parameter is included. 454 3. Otherwise, a "VALUE" parameter is included, and the value type is 455 used as the parameter value. 457 See Section 5 for information on handling unknown value types. 459 3.5.2. Multi-value Parameters 461 In [RFC5545], some parameters allow using a COMMA-separated list of 462 values. To ease processing in jCal, the value of such parameters 463 MUST be represented in an array containing the separated values. The 464 array elements MUST be string values. Single-value parameters can be 465 represented either using a single string value or an array with one 466 string element. A jCal parser MUST be able to understand both value 467 data types. An example for a such parameter is the iCalendar 468 "DELEGATED-FROM" and "DELEGATED-TO" parameter, more such parameters 469 may be added in extensions. 471 The iCalendar specification requires encapsulation between DQUOTE 472 characters if a parameter value contains a colon, a semicolon or a 473 comma. These extra DQUOTE characters do not belong to the actual 474 parameter value, and hence are not included when the parameter is 475 converted to jCal. 477 Example 1: 479 ["attendee", 480 { 481 "delegated-to": ["mailto:jdoe@example.org", 482 "mailto:jqpublic@example.org"] 483 }, 484 "cal-address", 485 "mailto:jsmith@example.org" 486 ] 488 Example 2: 490 ["attendee", 491 { 492 "delegated-to": "mailto:jdoe@example.org" 493 }, 494 "cal-address", 495 "mailto:jsmith@example.org" 496 ] 498 3.6. Values (RFC5545 section 3.3) 500 The following subsections specify how iCalendar property value data 501 types, which are defined in the subsections of [RFC5545] Section 3.3, 502 are represented in jCal. 504 3.6.1. Binary (RFC5545 section 3.3.1) 506 Description: iCalendar "BINARY" property values are represented by a 507 property with type identifier "binary". The value element is a 508 JSON string with base64 encoded data, conforming to Section 4 of 509 [RFC4648], which is the base64 method used in [RFC5545]. 511 Example: 513 ["attach", {}, "binary", "SGVsbG8gV29ybGQh"] 515 3.6.2. Boolean (RFC5545 section 3.3.2) 517 Description: iCalendar "BOOLEAN" property values are represented by 518 a property with the type identifier "boolean". The value is a 519 JSON boolean value. 521 Example: 523 ["x-non-smoking", {}, "boolean", true] 525 3.6.3. Calendar User Address (RFC5545 section 3.3.3) 527 Description: iCalendar "CAL-ADDRESS" property values are represented 528 by a property with the type identifier "cal-address". The value 529 is a JSON string with the URI as described in [RFC3986]. 531 Example: 533 ["attendee", {}, "cal-address", "mailto:kewisch@example.com"] 535 3.6.4. Date (RFC5545 section 3.3.4) 537 Description: iCalendar "DATE" property values are represented by a 538 property with the type identifier "date". The value elements are 539 JSON strings with the same date value specified by [RFC5545], but 540 represented using the extended format of the complete 541 representation specified in [ISO.8601.2004], Section 4.1.2.2. 542 Other variations, for example representation with reduced 543 accuracy, MUST NOT be used. 545 ABNF Schema: 547 ; year, month and day rules are 548 ; defined in [ISO.8601.2004], Section 2.2. 550 date = year "-" month "-" day ;YYYY-MM-DD 552 Example: 554 ["dtstart", {}, "date", "2011-05-17"] 556 3.6.5. Date-Time (RFC5545 section 3.3.5) 558 Description: iCalendar "DATE-TIME" property values are represented 559 by a property with the type identifier "date-time". The value 560 elements are JSON strings with the same date value specified by 561 [RFC5545], but represented using the extended format of the 562 complete representation specified in [ISO.8601.2004], 563 Section 4.3.2. Other variations, for example representation with 564 reduced accuracy, MUST NOT be used. The same restrictions with 565 respect to leap seconds and timezone offsets as specified in 566 [RFC5545] Section 3.3.5 apply. 568 ABNF Schema: 570 ; year, month, day, hour, minute and second rules are 571 ; defined in [ISO.8601.2004], Section 2.2. 572 ; The zone identifier is described in [ISO.8601.2004], Section 4.3.2. 573 date-complete = year "-" month "-" day ;YYYY-MM-DD 574 time-complete = hour ":" minute ":" second [zone] ; HH:MM:SS 575 datetime = date-complete "T" time-complete 577 Examples: 579 ["dtstart", {}, "date-time", "2012-10-17T12:00:00"], 580 ["dtstamp", {}, "date-time", "2012-10-17T12:00:00Z"], 581 ["dtend", 582 { "tzid": "Europe/Berlin" }, 583 "date-time", 584 "2011-10-17T13:00:00" 585 ] 587 3.6.6. Duration (RFC5545 section 3.3.6) 589 Description: iCalendar "DURATION" property values are represented by 590 a property with the type identifier "duration". The value 591 elements are JSON strings with the same duration value specified 592 by [RFC5545]. 594 Example: 596 ["duration", {}, "duration", "P1D"] 598 3.6.7. Float (RFC5545 section 3.3.7) 600 Description: iCalendar "FLOAT" property values are represented by a 601 property with the type identifier "float". The value elements are 602 JSON primitive number values. 604 Example: 606 ["x-grade", {}, "float", 1.3] 608 3.6.8. Integer (RFC5545 section 3.3.8) 610 Description: vCard "INTEGER" property values are represented by a 611 property with the type identifier "integer". The value elements 612 are JSON primitive number values which MUST resolve to an integer 613 value in the range specified in [RFC5545], Section 3.3.8. Thus a 614 fractional and/or exponential part are only allowed under limited 615 circumstances. 617 Examples: 619 ["percent-complete", {}, "integer", 42] 621 3.6.9. Period of Time (RFC5545 section 3.3.9) 623 Description: iCalendar "PERIOD" property values are represented by a 624 jCal property with the type identifier "period". The value 625 element is an array of JSON strings, with the first element 626 representing the start of the period and the second element 627 representing the end of the period. As in [RFC5545], the start of 628 the period is always formatted as a date-time value and the end of 629 the period MUST be either a date-time or duration value. Any 630 date, date-time or duration values contained in the period value 631 MUST be formatted in accordance to the rules for date, date-time 632 or duration values specified in this document. 634 Example: 636 ["freebusy", 637 { "fbtype": "FREE" }, 638 "period", 640 ["1997-03-08T16:00:00Z", "P1D"] 641 ] 643 3.6.10. Recurrence Rule (RFC5545 section 3.3.10) 645 Description: iCalendar "RECUR" property values are represented by a 646 property with the type identifier "recur". The value elements are 647 objects describing the structured data as specified by [RFC5545]. 648 Each rule part is described by the combination of key and value. 649 The key specifies the name of the rule part and MUST be converted 650 to lowercase. The value of the rule part MUST be mapped by the 651 following rules: 653 * The value of the "freq" and "wkst" rule parts MUST be a string 654 as specified in [RFC5545], with case preserved. 656 * The value of the "until" rule part MUST be a date or date-time 657 value formatted in accordance to the rules for date or date- 658 time specified in this document. 660 * The "count" and "interval" rule parts MUST be specified as a 661 single JSON number value. 663 * The following rule parts can have one or more numeric values: 664 "bysecond", "byminute", "byhour", "bymonthday", "byyearday", 665 "byweekno", "bymonth", and "bysetpos". If a rule part contains 666 multiple values, an array of numbers MUST be used for that rule 667 part. Single-valued rule parts can be represented either using 668 a single number value, omitting the array completely, or an 669 array with one number element. A jCal parser MUST be able to 670 understand both data types. 672 * Similarly, the "byday" rule part can have one or more string 673 values. If it contains multiple values, an array of strings 674 MUST be used. As before, a single-valued rule part can be 675 represented either using a single string value or an array with 676 one string element, both of which a jCal parser MUST be able to 677 understand. 679 Example 1: 681 ["rrule", 682 {}, 683 "recur", 684 { 685 "freq": "YEARLY", 686 "count": 5, 687 "byday": [ "-1SU", "2MO" ], 688 "bymonth": 10 689 } 690 ] 692 Example 2: 694 ["rrule", 695 {}, 696 "recur", 697 { 698 "freq": "MONTHLY", 699 "interval": 2, 700 "bymonthday": [ 1, 15, -1 ], 701 "until": "2013-10-01" 702 } 703 ] 705 3.6.11. Text (RFC5545 section 3.3.11) 707 Description: iCalendar "TEXT" property values are represented by a 708 property with the type identifier "text". The value elements are 709 JSON strings. 711 Example: 713 ["comment", {}, "text", "hello, world"] 715 3.6.12. Time (RFC5545 section 3.3.12) 717 Description: iCalendar "TIME" property values are represented by a 718 property with the type identifier "time". The value elements are 719 JSON strings with the same time value specified by [RFC5545], but 720 represented using the extended format of the complete 721 representation specified in [ISO.8601.2004], Section 4.2.2.2. 722 Other variations, for example representation with reduced 723 accuracy, MUST NOT be used. The same restrictions with respect to 724 leap seconds, time fractions, and timezone offsets as specified in 725 [RFC5545] Section 3.3.12 apply. 727 ABNF Schema: 729 ; hour, minute and second rules are 730 ; defined in [ISO.8601.2004], Section 2.2. 731 ; The zone identifier is described in [ISO.8601.2004], Section 4.3.2. 733 time-complete = hour ":" minute ":" second [zone] ; HH:MM:SS 735 Example: 737 ["x-time-local", {}, "time", "12:30:00"], 738 ["x-time-utc", {}, "time", "12:30:00Z"], 739 ["x-time-offset", { "tzid": "Europe/Berlin" }, "time", "12:30:00"] 741 3.6.13. URI (RFC5545 section 3.3.13) 743 Description: iCalendar "URI" property values are represented by a 744 property with the type identifier "uri". The value elements are 745 JSON strings representing the URI. 747 Example: 749 ["tzurl", {}, "uri", "http://example.org/tz/Europe-Berlin.ics"] 751 3.6.14. UTC Offset (RFC5545 section 3.3.14) 753 Description: iCalendar "UTC-OFFSET" property values are represented 754 by a property with the type identifier "utc-offset". The value 755 elements are JSON strings with the same UTC offset value specified 756 by [RFC5545], with the exception that the hour and minute 757 components are separated by a ":" character, for consistency with 758 the [ISO.8601.2004] timezone offset, extended format. 760 Example: 762 ["tzoffsetfrom", {}, "utc-offset", "-05:00"], 763 ["tzoffsetto", {}, "utc-offset", "+12:45"] 765 3.7. Extensions 767 iCalendar extension properties and property parameters (those with an 768 "X-" prefix in their name) are handled in the same way as other 769 properties and property parameters: the property is represented by an 770 array, the property parameter represented by an object. The property 771 or parameter name uses the same name as for the iCalendar extension, 772 but in lowercase. For example, the "X-FOO" property in iCalendar 773 turns into the "x-foo" jCal property. See Section 5 for how to deal 774 with default values for unrecognized extension properties or property 775 parameters. 777 4. Converting from jCal into iCalendar 779 Converting jCal to iCalendar reverses the process described in 780 Section 3. This section describes a few additional requirements for 781 conversion. 783 When converting component, property and property parameter names, 784 they names SHOULD be converted to uppercase. Although iCalendar 785 names are case insensitive, common practice is to keep them all 786 uppercase following the actual definitions in [RFC5545]. 788 During conversion, JSON escaping MUST be unescaped. Afterwards, 789 iCalendar escaping, as defined by [RFC5545] and [RFC6868] MUST be 790 applied. Finally, long lines SHOULD be folded as described in 791 [RFC5545], Section 3.1. 793 Non-binary value types MUST NOT be base64 encoded. 795 When converting to iCalendar, the VALUE parameter MUST be added to 796 properties whose default value type is unknown, but do not have a 797 jCal type identifier "unknown". The VALUE parameter MAY be omitted 798 for properties using the default value type. The VALUE parameter 799 MUST be omitted for properties which have the jCal type identifier 800 "unknown". 802 5. Handling Unrecognized Properties or Parameters 804 In iCalendar, properties can have one or more value types as 805 specified by their definition, with one of those values being defined 806 as the default. When a property uses its default value type, the 807 "VALUE" property parameter does not need to be specified on the 808 property. For example, "DTSTART"'s default value type is "DATE- 809 TIME", so "VALUE=DATE-TIME" need not be set as a property parameter. 810 However, "DTSTART" also allows a "DATE" value to be specified, and if 811 that is used, "VALUE=DATE" has to be set as a property parameter. 813 When new properties are defined or "X-" properties used, an iCalendar 814 to jCal converter might not recognize them, and not know what the 815 appropriate default value types are, yet they need to be able to 816 preserve the values. A similar issue arises for unrecognized 817 property parameters. 819 In jCal, a new "unknown" property value type is introduced. Its 820 purpose is to allow preserving unknown property values when round- 821 tripping between jCal and iCalendar. To avoid collisions, this 822 specification reserves the UNKNOWN property value type in iCalendar. 823 It MUST NOT be used in any iCalendar as specified by [RFC5545], nor 824 any extensions to it. The type is hence registered to the iCalendar 825 Value Data Types registry in Section 7.1. 827 5.1. Converting iCalendar into jCal 829 Any property that does not include a "VALUE" property parameter and 830 whose default value type is not known, MUST be converted to a 831 primitive JSON string. The content of that string is the unprocessed 832 value text. Also, value type MUST be set to "unknown". 834 To correctly implement this format, it is critical that if the 835 default type is not known that the type "unknown" is used. If this 836 requirement is ignored and for example "text" is used, additional 837 escaping may occur which breaks round-tripping values. 839 Any unrecognized property parameter MUST be converted to a string 840 value, with its content set to the property parameter value text, 841 treated as if it were a "TEXT" value. 843 5.2. Converting jCal into iCalendar 845 In jCal the value type is always explicitly specified. It is 846 converted to iCalendar using the iCalendar VALUE parameter, except in 847 the following two cases: 849 o If the value type specified in jCal matches the default value type 850 in iCalendar, the VALUE parameter MAY be omitted. 852 o If the value type specified in jCal is set to "unknown", the VALUE 853 parameter MUST NOT be specified. The value MUST be taken over in 854 iCalendar without processing. 856 5.3. Examples 858 The following is an example of an unrecognized iCalendar property 859 (that uses a "DATE-TIME" value as its default), and the equivalent 860 jCal representation of that property. 862 iCalendar: 864 X-COMPLAINT-DEADLINE:20110512T120000Z 865 jCal: 867 ["x-complaint-deadline", {}, "unknown", "20110512T120000Z"] 869 The following is an example of how to cope with jCal data where the 870 parser was unable to identify the type. Note how the "unknown" value 871 type is not added to the iCalendar data and escaping, aside from 872 standard JSON string escaping, is not processed. 874 jCal: 876 ["x-coffee-data", {}, "unknown", "Stenophylla;Guinea\\,Africa"] 878 iCalendar: 880 X-COFFEE-DATA:Stenophylla;Guinea\,Africa 882 The following is an example of a jCal property (where the 883 corresponding iCalendar property uses a "INTEGER" value as its 884 default), and the equivalent iCalendar representation of that 885 property. 887 jCal: 889 ["percent-complete", {}, "integer", 95] 891 iCalendar: 893 PERCENT-COMPLETE:95 895 The following is an example of an unrecognized iCalendar property 896 parameter (that uses a "FLOAT" value as its default) specified on a 897 recognized iCalendar property, and the equivalent jCal representation 898 of that property and property parameter. 900 iCalendar: 902 DTSTART;X-SLACK=30.3;VALUE=DATE:20110512 903 jCal: 905 ["dtstart", { "x-slack": "30.3" }, "date", "2011-05-12"] 907 6. Security Considerations 909 This specification defines how iCalendar data can be "translated" 910 between two different data formats - the original text format and 911 JSON - with a one-to-one mapping to ensure all the semantic data in 912 one format (properties, parameters and values) are preserved in the 913 other. It does not change the semantic meaning of the underlying 914 data itself, or impose or remove any security considerations that 915 apply to the underlying data. 917 The use of JSON as a format does have its own inherent security risks 918 as discussed in Section 12 of [RFC7159]. Even though JSON is 919 considered a safe subset of JavaScript, it should be kept in mind 920 that a flaw in the parser processing JSON could still impose a threat 921 which doesn't arise with conventional iCalendar data. 923 With this in mind, a parser for JSON data should be used for jCal 924 that is aware of the security implications. For example, the use of 925 JavaScript's eval() function is considered an unacceptable security 926 risk, as described in [RFC7159], Section 12. A native parser with 927 full awareness of the JSON format should be preferred. 929 In addition, it is expected that this new format will result in 930 iCalendar data being more widely disseminated (e.g., with use in web 931 applications rather than just dedicated calendaring applications). 933 In all cases, application developers have to conform to the semantics 934 of the iCalendar data as defined by [RFC5545] and associated 935 extensions, and all of the security considerations described in 936 Section 7 of [RFC5545], or any associated extensions, are applicable. 938 7. IANA Considerations 940 This document defines a MIME media type for use with iCalendar in 941 JSON data. This media type SHOULD be used for the transfer of 942 calendaring data in JSON. 944 Type name: application 946 Subtype name: calendar+json 948 Required parameters: none 949 Optional parameters: "method", "component" and "optinfo" as defined 950 for the text/calendar media type in [RFC5545], Section 8.1. 952 Encoding considerations: Same as encoding considerations of 953 application/json as specified in [RFC7159], Section 11. 955 Security considerations: See Section 6. 957 Interoperability considerations: This media type provides an 958 alternative format for iCalendar data based on JSON. 960 Published specification: This specification. 962 Applications which use this media type: Applications that currently 963 make use of the text/calendar media type can use this as an 964 alternative. Similarly, Applications that use the application/ 965 json media type to transfer calendaring data can use this to 966 further specify the content. 968 Fragment identifier considerations: N/A 970 Additional information: 972 Deprecated alias names for this type: N/A 974 Magic number(s): N/A 976 File extension(s): N/A 978 Macintosh file type code(s): N/A 980 Person & email address to contact for further information: 981 calsify@ietf.org 983 Intended usage: COMMON 985 Restrictions on usage: There are no restrictions on where this media 986 type can be used. 988 Author: See the "Author's Address" section of this document. 990 Change controller: IETF 992 7.1. UNKNOWN iCalendar Value Data Type 994 IANA is asked to add the following entry to the iCalendar Data Types 995 registry: 997 Value name: UNKNOWN 999 Purpose: To allow preserving property values whose default value 1000 type is not known during round-tripping between jCal and 1001 iCalendar. 1003 Format definition: (Not applicable) 1005 Description: The UNKNOWN value data type is reserved for the 1006 exclusive use of the jCal format. Its use is described in 1007 Section 5 of this document. 1009 Example: As this registration serves as a reservation of the UNKNOWN 1010 type so that it is not used in iCalendar, there is no applicable 1011 iCalendar example. Examples of its usage in jCal can be found in 1012 this document. 1014 IANA is asked to make the "Status" column for this entry in the 1015 registry say, "Reserved - Do not use" and to make the "Reference" 1016 column refer to Section 5 of this document. 1018 8. Acknowledgments 1020 The authors would like to thank the following for their valuable 1021 contributions: William Gill, Erwin Rehme, and Dave Thewlis, Simon 1022 Perreault, Michael Angstadt, Peter Saint-Andre, Bert Greevenbosch, 1023 Javier Godoy. This specification originated from the work of the 1024 XML-JSON technical committee of the Calendaring and Scheduling 1025 Consortium. 1027 9. References 1029 9.1. Normative References 1031 [ISO.8601.2004] 1032 International Organization for Standardization, ""Data 1033 elements and interchange formats -- Information 1034 interchange -- Representation of dates and times" ", ISO 1035 8601, 12 2004. 1037 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1038 Requirement Levels", BCP 14, RFC 2119, March 1997. 1040 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1041 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1042 3986, January 2005. 1044 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1045 Encodings", RFC 4648, October 2006. 1047 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1048 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1050 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 1051 Core Object Specification (iCalendar)", RFC 5545, 1052 September 2009. 1054 [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML 1055 Format for iCalendar", RFC 6321, August 2011. 1057 [RFC6868] Daboo, C., "Parameter Value Encoding in iCalendar and 1058 vCard", RFC 6868, February 2013. 1060 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1061 Interchange Format", RFC 7159, March 2014. 1063 9.2. Informative References 1065 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1066 Code: The Implementation Status Section", RFC 6982, July 1067 2013. 1069 [calconnect-artifacts] 1070 The Calendaring and Scheduling Consortium, "Code Artifacts 1071 and Schemas", , 1072 . 1074 Appendix A. Implementation Status (to be removed prior to publication 1075 as an RFC, as well as the reference to RFC6982) 1077 This section records the status of known implementations of the 1078 protocol defined by this specification at the time of posting of this 1079 Internet-Draft, and is based on a proposal described in [RFC6982]. 1080 The description of implementations in this section is intended to 1081 assist the IETF in its decision processes in progressing drafts to 1082 RFCs. Please note that the listing of any individual implementation 1083 here does not imply endorsement by the IETF. Furthermore, no effort 1084 has been spent to verify the information presented here that was 1085 supplied by IETF contributors. This is not intended as, and must not 1086 be construed to be, a catalog of available implementations or their 1087 features. Readers are advised to note that other implementations may 1088 exist. 1090 According to [RFC6982], "this will allow reviewers and working groups 1091 to assign due consideration to documents that have the benefit of 1092 running code, which may serve as evidence of valuable experimentation 1093 and feedback that have made the implemented protocols more mature. 1094 It is up to the individual working groups to use this information as 1095 they see fit". 1097 1. ICAL.js - Philipp Kewisch, James Lal. A JavaScript parser for 1098 iCalendar (rfc5545) 1100 Source: https://github.com/mozilla-comm/ical.js/ 1102 Maturity: production 1104 Coverage: All aspects of this draft, up to version 01. Includes 1105 an online validator. (as of rev 847c67c501, 2013-02-14) 1107 Licensing: MPL, Mozilla Public License 2.0 1109 2. Py Calendar - Cyrus Daboo. iCalendar/vCard Library 1111 Source: https://svn.calendarserver.org/repository/calendarserver 1112 /PyCalendar/branches/json/ 1114 Maturity: production 1116 Coverage: All aspects of this draft, up to version 01. 1118 Licensing: Apache License, Version 2.0 1120 Additionally, interoperability testing of this draft is an ongoing 1121 effort under members of calconnect, the Calendaring and Scheduling 1122 Consortium. CalDAV Vendors are looking into supporting this draft. 1124 Appendix B. ABNF Schema 1126 Below is an ABNF schema as per [RFC5234] for iCalendar in JSON. ABNF 1127 Symbols not described here are taken from [RFC7159]. The schema is 1128 non-normative and given for reference only. 1130 The numeric section numbers given in the comments refer to section in 1131 [RFC5545]. Additional semantic restrictions apply, especially 1132 regarding the allowed properties and sub-components per component. 1133 Details on these restrictions can be found in this document and 1134 [RFC5545]. 1136 Additional schemas may be available on the internet at 1137 [calconnect-artifacts]. 1139 ; A jCal Object is a component with the component-name "vcalendar". 1140 ; Restrictions to which properties and sub-components may be 1141 ; specified are to be taken from RFC5545. 1142 jcalobject = component 1144 ; A jCal component consists of the name string, properties array and 1145 ; component array 1146 component = begin-array 1147 DQUOTE component-name DQUOTE value-separator 1148 properties-array value-separator 1149 components-array 1150 end-array 1152 components-array = begin-array 1153 [ component *(value-separator component) ] 1154 end-array 1156 ; A jCal property consists of the name string, parameters object, 1157 ; type string and one or more values as specified in this document. 1158 property = begin-array 1159 DQUOTE property-name DQUOTE value-separator 1160 params-object value-separator 1161 DQUOTE type-name DQUOTE 1162 property-value *(value-separator property-value) 1163 end-array 1164 properties-array = begin-array 1165 [ property *(value-separator property) ] 1166 end-array 1168 ; Property values depend on the type-name. Aside from the value types 1169 ; mentioned here, extensions may make use of other JSON value types. 1170 ; The non-terminal symbol structured-prop-value covers the special 1171 ; cases for GEO and REQUEST-STATUS 1172 property-value = simple-prop-value / structured-prop-value 1173 simple-prop-value = string / number / true / false 1174 structured-prop-value = 1175 begin-array 1176 [ structured-element *(value-separator structured-element) ] 1177 end-array 1178 structured-element = simple-prop-value 1180 ; The jCal params-object is a JSON object which follows the semantic 1181 ; guidelines described in this document. 1182 params-object = begin-object 1183 [ params-member *(value-separator params-member) ] 1184 end-object 1185 params-member = DQUOTE param-name DQUOTE name-separator param-value 1186 param-value = string / param-multi 1187 param-multi = begin-array 1188 [ string *(value-separator string) ] 1189 end-array 1191 ; The type MUST be a valid type as described by this document. New 1192 ; value types can be added by extensions. 1193 type-name = "binary" / "boolean" / "cal-address" / "date" / 1194 "date-time" / "duration" / "float" / "integer" / 1195 "period" / "recur" / "text" / "time" / "uri" / 1196 "utc-offset" / x-type 1198 ; Component, property, parameter and type names MUST be lowercase. 1199 ; Additional semantic restrictions apply as described by this 1200 ; document and RFC5545. 1201 component-name = lowercase-name 1202 property-name = lowercase-name 1203 param-name = lowercase-name 1204 x-type = lowercase-name 1205 lowercase-name = 1*(%x61-7A / DIGIT / "-") 1207 Appendix C. Examples 1209 This section contains two examples of iCalendar objects with their 1210 jCal representation. 1212 C.1. Example 1 1214 C.1.1. iCalendar Data 1216 BEGIN:VCALENDAR 1217 CALSCALE:GREGORIAN 1218 PRODID:-//Example Inc.//Example Calendar//EN 1219 VERSION:2.0 1220 BEGIN:VEVENT 1221 DTSTAMP:20080205T191224Z 1222 DTSTART:20081006 1223 SUMMARY:Planning meeting 1224 UID:4088E990AD89CB3DBB484909 1225 END:VEVENT 1226 END:VCALENDAR 1228 C.1.2. jCal Data 1230 ["vcalendar", 1231 [ 1232 ["calscale", {}, "text", "GREGORIAN"], 1233 ["prodid", {}, "text", "-//Example Inc.//Example Calendar//EN"], 1234 ["version", {}, "text", "2.0"] 1235 ], 1236 [ 1237 ["vevent", 1238 [ 1239 ["dtstamp", {}, "date-time", "2008-02-05T19:12:24Z"], 1240 ["dtstart", {}, "date", "2008-10-06"], 1241 ["summary", {}, "text", "Planning meeting"], 1242 ["uid", {}, "text", "4088E990AD89CB3DBB484909"] 1243 ], 1244 [] 1245 ] 1246 ] 1247 ] 1249 C.2. Example 2 1251 C.2.1. iCalendar Data 1253 BEGIN:VCALENDAR 1254 VERSION:2.0 1255 PRODID:-//Example Corp.//Example Client//EN 1256 BEGIN:VTIMEZONE 1257 LAST-MODIFIED:20040110T032845Z 1258 TZID:US/Eastern 1259 BEGIN:DAYLIGHT 1260 DTSTART:20000404T020000 1261 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1262 TZNAME:EDT 1263 TZOFFSETFROM:-0500 1264 TZOFFSETTO:-0400 1265 END:DAYLIGHT 1266 BEGIN:STANDARD 1267 DTSTART:20001026T020000 1268 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1269 TZNAME:EST 1270 TZOFFSETFROM:-0400 1271 TZOFFSETTO:-0500 1272 END:STANDARD 1273 END:VTIMEZONE 1274 BEGIN:VEVENT 1275 DTSTAMP:20060206T001121Z 1276 DTSTART;TZID=US/Eastern:20060102T120000 1277 DURATION:PT1H 1278 RRULE:FREQ=DAILY;COUNT=5 1279 RDATE;TZID=US/Eastern;VALUE=PERIOD:20060102T150000/PT2H 1280 SUMMARY:Event #2 1281 DESCRIPTION:We are having a meeting all this week at 12 pm fo 1282 r one hour\, with an additional meeting on the first day 2 h 1283 ours long.\nPlease bring your own lunch for the 12 pm meetin 1284 gs. 1285 UID:00959BC664CA650E933C892C@example.com 1286 END:VEVENT 1287 BEGIN:VEVENT 1288 DTSTAMP:20060206T001121Z 1289 DTSTART;TZID=US/Eastern:20060104T140000 1290 DURATION:PT1H 1291 RECURRENCE-ID;TZID=US/Eastern:20060104T120000 1292 SUMMARY:Event #2 bis 1293 UID:00959BC664CA650E933C892C@example.com 1294 END:VEVENT 1295 END:VCALENDAR 1297 C.2.2. jCal Data 1299 ["vcalendar", 1300 [ 1301 ["prodid", {}, "text", "-//Example Corp.//Example Client//EN"], 1302 ["version", {}, "text", "2.0"] 1303 ], 1304 [ 1305 ["vtimezone", 1306 [ 1307 ["last-modified", {}, "date-time", "2004-01-10T03:28:45Z"], 1308 ["tzid", {}, "text", "US/Eastern"] 1309 ], 1310 [ 1312 ["daylight", 1313 [ 1314 ["dtstart", {}, "date-time", "2000-04-04T02:00:00"], 1315 ["rrule", 1316 {}, 1317 "recur", 1318 { 1319 "freq": "YEARLY", 1320 "byday": "1SU", 1321 "bymonth": 4 1322 } 1323 ], 1324 ["tzname", {}, "text", "EDT"], 1325 ["tzoffsetfrom", {}, "utc-offset", "-05:00"], 1326 ["tzoffsetto", {}, "utc-offset", "-04:00"] 1327 ], 1328 [] 1329 ], 1330 ["standard", 1331 [ 1332 ["dtstart", {}, "date-time", "2000-10-26T02:00:00"], 1333 ["rrule", 1334 {}, 1335 "recur", 1336 { 1337 "freq": "YEARLY", 1338 "byday": "1SU", 1339 "bymonth": 10 1340 } 1341 ], 1342 ["tzname", {}, "text", "EST"], 1343 ["tzoffsetfrom", {}, "utc-offset", "-04:00"], 1344 ["tzoffsetto", {}, "utc-offset", "-05:00"] 1345 ], 1346 [] 1347 ] 1348 ] 1349 ], 1350 ["vevent", 1351 [ 1352 ["dtstamp", {}, "date-time", "2006-02-06T00:11:21Z"], 1353 ["dtstart", 1354 { "tzid": "US/Eastern" }, 1355 "date-time", 1356 "2006-01-02T12:00:00" 1357 ], 1358 ["duration", {}, "duration", "PT1H"], 1359 ["rrule", {}, "recur", { "freq": "DAILY", "count": 5 } ], 1361 ["rdate", 1362 { "tzid": "US/Eastern" }, 1363 "period", 1364 "2006-01-02T15:00:00/PT2H" 1365 ], 1366 ["summary", {}, "text", "Event #2"], 1367 ["description", 1368 {}, 1369 "text", 1370 // Note that comments and string concatenation are not 1371 // allowed per JSON specification and is used here only 1372 // to avoid long lines. 1373 "We are having a meeting all this week at 12 pm for one " + 1374 "hour, with an additional meeting on the first day 2 " + 1375 "hours long.\nPlease bring your own lunch for the 12 pm " + 1376 "meetings." 1377 ], 1378 ["uid", {}, "text", "00959BC664CA650E933C892C@example.com"] 1379 ], 1380 [] 1381 ], 1382 ["vevent", 1383 [ 1384 ["dtstamp", {}, "date-time", "2006-02-06T00:11:21Z"], 1385 ["dtstart", 1386 { "tzid": "US/Eastern" }, 1387 "date-time", 1388 "2006-01-02T14:00:00" 1389 ], 1390 ["duration", {}, "duration", "PT1H"], 1391 ["recurrence-id", 1392 { "tzid": "US/Eastern" }, 1393 "date-time", 1394 "2006-01-04T12:00:00" 1395 ], 1396 ["summary", {}, "text", "Event #2"], 1397 ["uid", {}, "text", "00959BC664CA650E933C892C@example.com"] 1398 ], 1399 [] 1400 ] 1401 ] 1402 ] 1404 Appendix D. Change History (to be removed prior to publication as an 1405 RFC) 1407 draft-kewisch-et-al-icalendar-in-json-01 1408 * Added information on how to handle multi-value parameter. The 1409 decision leads to a cleaner draft for a similar proposal for 1410 vcard. 1412 * Removed the open discussion point section regarding the mime 1413 media type in favor of adding one. 1415 * Minor corrections in wording and typo fixes. 1417 draft-kewisch-et-al-icalendar-in-json-02 1419 * Added implementation status section. 1421 * Removed various text tables that just show a conversion from 1422 uppercase to lowercase. 1424 * Changed value format for RECUR and PERIOD types 1426 * Minor corrections in wording and typo fixes. 1428 draft-ietf-jcardcal-jcal-00 1430 * Publication as a WG draft 1432 draft-ietf-jcardcal-jcal-01 1434 * Changed handling of GEO and REQUEST-STATUS to align with jCard 1436 * Corrections and additions to the ABNF Section 1438 * Added a further sentence on preprocessing and escaping to 1439 clarify that JSON escaping must be used. 1441 draft-ietf-jcardcal-jcal-02 1443 * Changed handling of unknown property parameter types. 1445 * Minor corrections and fixing typos. 1447 draft-ietf-jcardcal-jcal-03 1449 * Changed wording around RECUR value handling. 1451 * Minor corrections and fixing typos. 1453 draft-ietf-jcardcal-jcal-04 1455 * Changed wording around RECUR value handling again. 1457 * Added reference to rfc6868 for both directions 1459 * Resolved a few MAY/SHOULD conflicts 1461 * Improved UNKNOWN registration by only putting iCalendar related 1462 information into the registration template. 1464 * Removed the stream construct, replaced with general information 1465 on how to handle iCalendar streams. 1467 * Corrected some examples and ABNF 1469 draft-ietf-jcardcal-jcal-06 1471 * Corrected trailing commas in some examples. 1473 * Corrected rrule examples to use object syntax. 1475 * Corrected "request-status" example to use an array. 1477 * Updated UNKNOWN registration text as per iCalendar expert 1478 suggestion. 1480 draft-ietf-jcardcal-jcal-07 1482 * Minor fix in an example. 1484 draft-ietf-jcardcal-jcal-08 1486 * Editorial changes for alignment with draft-ietf-jcardcal-jcard. 1488 draft-ietf-jcardcal-jcal-09 1490 * Editorial changes in preparation for IETF last call. 1492 * Removed reference to jcard draft 1494 * Made more clear that parsers MUST be able to understand both 1495 single-valued and array data types. 1497 draft-ietf-jcardcal-jcal-10 1499 * Updated references from rfc4627 to rfc7159 1501 * Added a paragraph on number formats between iCalendar and JSON 1502 * Additions and corrections to conversion from jCal to iCalendar 1503 and moved redundant paragraph from Section 3.1 to 4. 1505 * Addded references to ISO.8501.2004 for ABNF of date/time rules. 1507 * Fixed typos in informative ABNF 1509 Authors' Addresses 1511 Philipp Kewisch 1512 Mozilla Corporation 1513 650 Castro Street, Suite 300 1514 Mountain View, CA 94041 1515 USA 1517 EMail: mozilla@kewis.ch 1518 URI: http://www.mozilla.org/ 1520 Cyrus Daboo 1521 Apple Inc. 1522 1 Infinite Loop 1523 Cupertino, CA 95014 1524 USA 1526 EMail: cyrus@daboo.name 1527 URI: http://www.apple.com/ 1529 Mike Douglass 1530 Rensselaer Polytechnic Institute 1531 110 8th Street 1532 Troy, NY 12180 1533 USA 1535 EMail: douglm@rpi.edu 1536 URI: http://www.rpi.edu/