idnits 2.17.1 draft-ietf-jcardcal-jcard-03.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (May 18, 2013) is 3995 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) == Outdated reference: A later version (-10) exists of draft-ietf-jcardcal-jcal-00 == Outdated reference: A later version (-06) exists of draft-sheffer-running-code-02 -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 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 May 18, 2013 5 Expires: November 19, 2013 7 jCard: The JSON format for vCard 8 draft-ietf-jcardcal-jcard-03 10 Abstract 12 This specification defines "jCard", a JSON format for vCard data. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on November 19, 2013. 31 Copyright Notice 33 Copyright (c) 2013 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 50 3. Converting from vCard to jCard . . . . . . . . . . . . . . . 4 51 3.1. Pre-processing . . . . . . . . . . . . . . . . . . . . . 4 52 3.2. vCard Stream . . . . . . . . . . . . . . . . . . . . . . 4 53 3.3. Properties (RFC6350 section 6) . . . . . . . . . . . . . 5 54 3.3.1. Special Cases for Properties . . . . . . . . . . . . 6 55 3.3.1.1. Multi-valued Properties . . . . . . . . . . . . . 6 56 3.3.1.2. Grouping of Properties . . . . . . . . . . . . . 7 57 3.3.1.3. Structured Property Values . . . . . . . . . . . 8 58 3.4. Parameters (RFC6350 Section 5) . . . . . . . . . . . . . 9 59 3.4.1. VALUE parameter . . . . . . . . . . . . . . . . . . . 10 60 3.4.2. Multi-value Parameters . . . . . . . . . . . . . . . 10 61 3.5. Values (RFC6350 Section 4) . . . . . . . . . . . . . . . 11 62 3.5.1. Text (RFC6350 Section 4.1) . . . . . . . . . . . . . 11 63 3.5.2. URI (RFC6350 Section 4.2) . . . . . . . . . . . . . . 11 64 3.5.3. Date (RFC6350 Section 4.3.1) . . . . . . . . . . . . 12 65 3.5.4. Time (RFC6350 Section 4.3.2) . . . . . . . . . . . . 13 66 3.5.5. Date-Time (RFC6350 Section 4.3.3) . . . . . . . . . . 14 67 3.5.6. Date and/or Time (RFC6350 Section 4.3.4) . . . . . . 15 68 3.5.7. Timestamp (RFC6350 Section 4.3.5) . . . . . . . . . . 16 69 3.5.8. Boolean (RFC6350 Section 4.4) . . . . . . . . . . . . 16 70 3.5.9. Integer (RFC6350 Section 4.5) . . . . . . . . . . . . 17 71 3.5.10. Float (RFC6350 Section 4.6) . . . . . . . . . . . . . 17 72 3.5.11. UTC Offset (RFC6350 Section 4.7) . . . . . . . . . . 17 73 3.5.12. Language Tag (RFC6350 Section 4.8) . . . . . . . . . 18 74 3.6. Extensions (RFC6350 Section 6.10) . . . . . . . . . . . . 18 75 4. Converting from jCard into vCard . . . . . . . . . . . . . . 18 76 5. Handling Unrecognized Properties or Parameters . . . . . . . 19 77 6. Implementation Status (to be removed prior to publication as 78 an RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 81 8.1. GROUP vCard Parameter . . . . . . . . . . . . . . . . . . 23 82 8.2. UNKNOWN vCard Value Data Type . . . . . . . . . . . . . . 23 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 86 10.2. Informative References . . . . . . . . . . . . . . . . . 25 87 Appendix A. ABNF Schema . . . . . . . . . . . . . . . . . . . . 25 88 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 27 89 B.1. Example: vCard of the author of RFC6350 . . . . . . . . . 27 90 B.1.1. vCard Data . . . . . . . . . . . . . . . . . . . . . 27 91 B.1.2. jCard Data . . . . . . . . . . . . . . . . . . . . . 28 92 Appendix C. Change History (to be removed prior to publication 93 as an RFC) . . . . . . . . . . . . . . . . . . . . . 29 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 96 1. Introduction 98 The vCard data format [RFC6350] has gone through multiple revisions, 99 most recently vCard 4. The goal followed by this format is the 100 capture and exchange of information normally stored within an address 101 book or directory application. As certain similarities to the 102 iCalendar data format [RFC5545] exist it makes sense to define a 103 JSON-based data format for vCards that is similar to the jCal format 104 defined in [I-D.ietf-jcardcal-jcal]. 106 The purpose of this specification is to define "jCard", a JSON format 107 for vCard data. One main advantage to using a JSON-based format as 108 defined in [RFC4627] over the classic vCard format is easier 109 processing for JavaScript based widgets and libraries, especially in 110 the scope of web-based applications. 112 The key design considerations are essentially the same as those for 113 [I-D.ietf-jcardcal-jcal] and [RFC6321], that is: 115 Round-tripping (converting a vCard instance to jCard and back) 116 will give the same semantic result as the starting point. For 117 example, all components, properties and property parameters are 118 guaranteed to be preserved. 120 Ordering of elements will not necessarily be preserved. 122 Preserve the semantics of the vCard data. While a simple consumer 123 can easily browse the data in jCard, a full understanding of vCard 124 is still required in order to modify and/or fully comprehend the 125 directory data. 127 Ability to handle many extensions to the underlying vCard 128 specification without requiring an update to this document. 130 2. Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 The underlying format used for jCard is JSON. Consequently, the 137 terms "object" and "array" as well as the four primitive types are to 138 be interpreted as described in Section 1 of [RFC4627]. 140 Some examples in this document contain "partial" JSON documents used 141 for illustrative purposes. In these examples, three periods "..." 142 are used to indicate a portion of the document that has been removed 143 for compactness. 145 3. Converting from vCard to jCard 147 This section describes how vCard data is converted to jCard using a 148 simple mapping between the vCard data model and JSON elements. 150 3.1. Pre-processing 152 vCard uses a line folding mechanism to limit lines of data to a 153 maximum line length (typically 72 characters) to ensure maximum 154 likelihood of preserving data integrity as it is transported via 155 various means (e.g., email) - see Section 3.2 of [RFC6350]. Prior to 156 converting vCard data into jCard all folded lines MUST be unfolded. 158 vCard data uses an "escape" character sequence for text values and 159 property parameter values. When such text elements are converted 160 into jCard the escaping MUST be removed. See Section 3.4 of 161 [RFC6350]. The only escaping that may be applied is any escaping 162 mandated by JSON. 164 One key difference in the formatting of values used in vCard and 165 jCard is that in jCard the specification uses date/time values 166 aligned with the extended format of [ISO.8601.2004]. The sections of 167 this document describing the various date and time formats contain 168 more information on the use of the complete representation, reduced 169 accuracy or truncated representation. 171 3.2. vCard Stream 173 In certain cases it makes sense to group a sequence of vcard objects 174 into a stream of objects. While the vCard 4 standard doesn't define 175 a stream of vcard objects, having one makes it easier to identify 176 multiple jCard objects and also ensures compatibility to jCal. A 177 jCard stream is identified by an array, where the first element is 178 the string "vcardstream". Subsequent elements are vCard objects 179 represented as described in this document. 181 In the typical case where there is only one vCard object, 182 encapsulation inside a "vcardstream" array MAY be omitted. 184 A vCard stream can contain one or more vCard objects. Each vCard 185 object, delimited by "BEGIN:VCARD" and "END:VCARD", is represented in 186 JSON as a fixed length array with two elements: 188 1. The string "vcard" 190 2. An array of jCard properties 191 The representation of a vCard object in JSON will be named "vcard 192 component" throughout this document. 194 Example: 196 ["vcardstream", 197 ["vcard", 198 [ /* properties */ ] 199 ], 200 ["vcard", 201 [ /* properties */ ] 202 ], 203 ... 204 ] 206 vCard objects are comprised of a set of "properties", "parameters" 207 and "values". The top level of a vCard object contains "properties". 208 A "property" has a "value" and a set of zero or more "parameters". 209 vCard objects are delimited by the general properties "BEGIN" and 210 "END" with the fixed value "VCARD" as defined in Section 6.1.1 and 211 6.1.2 of [RFC6350]. In addition, the vCard format is versioned, 212 therefore the "version" property is mandatory. To comply with 213 Section 6.7.9 of [RFC6350], the value of the version property MUST be 214 "4.0". 216 3.3. Properties (RFC6350 section 6) 218 Each individual vCard property is represented in jCard by an array 219 with three fixed elements, followed by one or more additional 220 elements, depending on if the property is a multi-value property as 221 described in Section 3.3 of [RFC6350]. 223 The array consists of the following fixed elements: 225 1. The name of the property as a string, but in lowercase. 227 2. An object containing the parameters as described in Section 3.4. 229 3. The type identifier string of the value, in lowercase. 231 The remaining elements of the array are used for the value of the 232 property. For single-value properties, the array MUST have exactly 233 four elements, for multi-valued properties as described in 234 Section 3.3.1.1 there can be any number of additional elements. 236 The array describing the property can then be inserted into the array 237 designated for properties in the "vcard" component. 239 Example: 241 ["vcard", 242 [ 243 ["version", {}, "text", "4.0"], 244 ["fn", {}, "text", "John Doe"], 245 ["gender", {}, "text", "M"], 246 ... 247 ], 248 ] 250 The property parameters in the second element of the property array 251 associate a set of parameter names with their respective value. 252 Parameters are further described in Section 3.4. 254 To allow for a cleaner implementation, the parameter object MUST be 255 present even if there are no parameters. In this case, an empty 256 object MUST be used. 258 As described in Section 3.3.1.3, it is important to check the data 259 type of the value even if it is assumed to be a string in most cases. 260 The value could turn out to be a structured value, in which case the 261 type is an array. 263 3.3.1. Special Cases for Properties 265 This section describes some properties that have special handling 266 when converting to jCard. 268 3.3.1.1. Multi-valued Properties 270 Various vCard properties defined in [RFC6350], for example the 271 "CATEGORIES" property, are defined as multi-valued properties. In 272 jCal these properties are added as further members of the array 273 describing the property. 275 Note that additional multi-valued properties may be added in 276 extensions to the iCalendar format. 278 Example: 280 ["vcard", 281 [ 282 ["categories", {}, "text", "computers", "cameras"], 283 ... 284 ], 285 ... 286 ] 288 3.3.1.2. Grouping of Properties 290 [RFC6350] Section 3.3 defines a grouping construct that is used to 291 group related properties together. In jCard, a new GROUP parameter 292 is introduced. Its purpose is to eliminate the need for group syntax 293 in jCard, thus unifying the general syntax with that of jCal. 295 Namespace: 297 Parameter name: GROUP 299 Purpose: To simplify the jCard format. 301 Description: The GROUP parameter is reserved for the exclusive use 302 of the jCard format RFCTODO. It MUST NOT be used in plain vCard 303 [RFC6350], nor in xCard [RFC6351]. In jCard, the parameter's 304 value is a single opaque string. Conversion rules are as follows: 306 * From vCard to jCard, the group construct (see [RFC6350], 307 Section 3.3, Page 7) is removed. In its place, the GROUP 308 parameter is added (lowercased, as any other parameter). Its 309 value is a string corresponding to the group name. The name's 310 case MUST be preserved intact. 312 * From jCard to vCard, the reverse procedure is performed. The 313 GROUP parameter MUST NOT appear in the resulting vCard. 315 Format definition: (Not applicable) 317 Example: 319 CONTACT.FN:Mr. John Q. Public\, Esq. 321 is equivalent to: 323 [ "fn", { "group": "CONTACT" }, "text", "Mr. John Q. Public, Esq." ] 325 3.3.1.3. Structured Property Values 327 The vCard specification defines properties with structured values, 328 for example GENDER or ADR. A structured value is defined as a value 329 that contains multiple text components, delimited by the SEMICOLON 330 character. In jCard, the property value is an array containing one 331 element for each text component. 333 vCard Example: 335 ADR:;;123 Main Street;Any Town;CA;91921-1234;U.S.A. 337 jCard Example: 339 ["adr", {}, "text", 340 [ 341 "", "", "123 Main Street", 342 "Any Town", "CA", "91921-1234", "U.S.A." 343 ] 344 ] 346 Some vCard properties, for example ADR, also allow a structured value 347 element that itself has multiple values. In this case, the element 348 of the array describing the structured value is itself an array with 349 one element for each of the component's multiple values. 351 vCard Example: 353 ADR:;;My Street,Left Side,Second Shack;Hometown;PA;18252;U.S.A. 355 jCard Example: 357 ["adr", {}, "text", 358 [ 359 "", "", 360 ["My Street", "Left Side", "Second Shack"], 361 "Hometown", "PA", "18252", "U.S.A." 362 ] 363 ] 365 In both cases, the array element values MUST have the primitive type 366 that matches the jCard type identifier. In [RFC6350], there are only 367 structured text values and thus only JSON strings are used. 369 Extensions may for example define structured number or boolean 370 values, where JSON number or boolean types MUST be used. 372 If a multi-valued text component is changed to hold only one value, 373 the text component SHOULD be represented as a single primitive value, 374 but MAY be represented as an array with a single primitive value. 376 Similarly, structured values that consist of two text components with 377 one being optional (for example, GENDER) MAY be represented as a 378 single text value. Therefore, implementors SHOULD check even known 379 property values for structured information. This is especially 380 important for languages where accessing array members is done by the 381 same construct as accessing characters of a string. 383 Examples: 385 ["gender", {}, "text", ["F", "grrrl"] ], 386 ["gender", {}, "text", "M" ], 388 Per [RFC6350] Section 6.3.1, the component separator MUST be 389 specified even if the component value is missing. Similarly, the 390 jCard array containing the structured data MUST contain all required 391 elements, even if they are empty. 393 vCard Example: 395 ADR;LABEL="123 Maple Ave\nSuite 901\nVancouver BC\nA1B 2C9\nCan 396 ada":;;;;;; 398 jCard Example: 400 ["adr", 401 {"label":"123 Maple Ave\nSuite 901\nVancouver BC\nA1B 2C9\nCanada"}, 402 "text", 403 ["", "", "", "", "", "", ""] 404 ] 406 3.4. Parameters (RFC6350 Section 5) 408 Property parameters are represented as a JSON object where each key- 409 value pair represents the vCard parameter name and its value. The 410 name of the parameter MUST be in lowercase, the original case of the 411 parameter value MUST be preserved. For example, the "LANG" property 412 parameter is represented in jCard by the "lang" key. Any new vCard 413 parameters added in the future will be converted in the same way. 415 Example: 417 ["vcard", 418 [ 419 ["role", { "lang": "tr" }, "text", "roca"], 420 ... 421 ], 422 ... 423 ] 425 3.4.1. VALUE parameter 427 vCard defines a "VALUE" property parameter (Section 5.2 of 428 [RFC6350]). This property parameter MUST NOT be added to the 429 parameters object. Instead, the value type is always explicitly 430 mentioned in the third element of the array describing the property. 431 Thus, when converting from vCard to jCard, any "VALUE" property 432 parameters are skipped. When converting from jCard into vCard, the 433 appropriate "VALUE" property parameter MUST be included in the vCard 434 property if the value type is not "unknown" or the default value type 435 for that property. See Section 5 for information on handling unknown 436 value types. 438 3.4.2. Multi-value Parameters 440 In [RFC6350], some parameters allow using a COMMA-separated list of 441 values. To ease processing in jCard, the value to such parameters 442 MUST be represented in an array containing the separated values. The 443 array elements MUST be string values. Single-value parameters SHOULD 444 be represented using a single string value, but an array with one 445 element MAY also be used. An example for a such parameter is the 446 vCard "SORT-AS" parameter, more such parameters may be added in 447 extensions. 449 DQUOTE characters used to encapsulate the separated values MUST NOT 450 be added to the jCard parameter value. 452 Example 1: 454 ["vcard", 455 [ 456 ["n", 457 { "sort-as": ["Harten", "Rene"] }, 458 "text", 459 "van der Harten;Rene,J.;Sir;R.D.O.N." 460 ], 461 ["fn", {}, "text", "Rene van der Harten"] 462 ... 463 ], 464 ... 465 ] 467 3.5. Values (RFC6350 Section 4) 469 The type of a vCard value is explicitly mentioned in the third 470 element of the array describing a jCard property. The actual values 471 of the property can be found in the fourth and following elements of 472 the array. 474 3.5.1. Text (RFC6350 Section 4.1) 476 Description: vCard "TEXT" property values are represented by a 477 property with the type identifier "text". The value elements are 478 JSON strings. For details on structured text values, see 479 Section 3.3.1.3. 481 Example: 483 ... 484 ["kind", {}, "text", "group"], 485 ... 487 3.5.2. URI (RFC6350 Section 4.2) 489 Description: vCard "URI" property values are represented by a 490 property with the type identifier "uri". The value elements are 491 JSON strings. 493 Example: 495 ... 496 ["source", {}, "uri", "ldap://ldap.example.com/cn=babs%20jensen"], 497 ... 499 3.5.3. Date (RFC6350 Section 4.3.1) 501 Description: vCard "DATE" property values are represented by a 502 property with the type identifier "date". The value elements are 503 JSON strings with the same date value specified by [RFC6350], but 504 represented using the extended format specified in 505 [ISO.8601.2004], Section 4.1.2. If the complete representation is 506 not used, the same date format restrictions regarding reduced 507 accuracy, truncated representation and expanded representation 508 noted in [RFC6350] Section 4.1.2.3 apply. Whenever the extended 509 format is not applicable, the basic format MUST be used. 511 ABNF Schema: 513 date-complete = year "-" month "-" day ;YYYY-MM-DD 515 date-noreduc = date-complete 516 / "--" month "-" day; --MM-DD 517 / "---" day; ---DDD 519 date = date-noreduc 520 / year; YYYY 521 / year "-" month ; YYYY-MM 522 / "--" month; --MM 524 Examples: 526 ... 527 ["bday", {}, "date", "1985-04-12"], 528 ["bday", {}, "date", "1985-04"], 529 ["bday", {}, "date", "1985"], 530 ["bday", {}, "date", "--04-12"], 531 ["bday", {}, "date", "---12"], 532 ... 534 This table contains possible conversions between the vCard DATE 535 format its jCard date. This information is to be seen as an 536 informative reference, the normative reference is [ISO.8601.2000] and 537 [ISO.8601.2004]: 539 +-----------+----------+------------+ 540 | | vCard | jCard | 541 +-----------+----------+------------+ 542 | Complete | 19850412 | 1985-04-12 | 543 | | | | 544 | Reduced | 1985-04 | 1985-04 | 545 | | | | 546 | Reduced | 1985 | 1985 | 547 | | | | 548 | Truncated | --0412 | --04-12 | 549 | | | | 550 | Truncated | --04 | --04 | 551 | | | | 552 | Truncated | ---12 | ---12 | 553 +-----------+----------+------------+ 555 3.5.4. Time (RFC6350 Section 4.3.2) 557 Description: vCard "TIME" property values are represented by a 558 property with the type identifier "time". The value elements are 559 JSON strings with the same time value specified by [RFC6350], but 560 represented using the extended format specified in 561 [ISO.8601.2004], Section 4.2. If the complete representation is 562 not used, the same time format restrictions regarding reduced 563 accuracy, decimal fraction and truncated representation noted in 564 [RFC6350] Section 4.3.2 apply. Whenever the extended format is 565 not applicable, the basic format MUST be used. The seconds value 566 of 60 MUST only be used to account for positive "leap" seconds and 567 the midnight hour is always represented by 00, never 24. 568 Fractions of a second are not supported by this format. Contrary 569 to [I-D.ietf-jcardcal-jcal], UTC offsets are permitted within a 570 time value. 572 ABNF Schema: 574 time-notrunc = hour [":" minute [":" second]] [zone] 576 time = time-notrunc 577 / "-" minute ":" second [zone]; -mm:ss 578 / "-" minute [zone]; -mm 579 / "--" second [zone]; --ss 581 Examples: 583 ... 584 ["x-time-local", {}, "time", "12:30:00"], 585 ["x-time-utc", {}, "time", "12:30:00Z"], 586 ["x-time-offset", "time", "12:30:00-08:00"], 587 ["x-time-reduced", "time", "23"], 588 ["x-time-truncated", "time", "-30"], 589 ... 591 This table contains possible conversions between the vCard TIME 592 format its jCard time.This information is to be seen as an 593 informative reference, the normative reference is [ISO.8601.2000] and 594 [ISO.8601.2004]: 596 +-----------+--------+----------+ 597 | | vCard | jCard | 598 +-----------+--------+----------+ 599 | Complete | 232050 | 23:20:50 | 600 | | | | 601 | Reduced | 2320 | 23:20 | 602 | | | | 603 | Reduced | 23 | 23 | 604 | | | | 605 | Truncated | -2050 | -20:50 | 606 | | | | 607 | Truncated | -20 | -20 | 608 | | | | 609 | Truncated | --50 | --50 | 610 +-----------+--------+----------+ 612 Also, all combinations may have any zone designator appended, as in 613 the complete representation. 615 3.5.5. Date-Time (RFC6350 Section 4.3.3) 617 Description: vCard "DATE-TIME" property values are represented by a 618 property with the type identifier "date-time". The value elements 619 are JSON strings with the same date value specified by [RFC6350], 620 but represented using the extended format specified in 621 [ISO.8601.2004], Section 4.3. If the complete representation is 622 not used, the same date and time format restrictions as in 623 Section 3.5.4 and Section 3.5.3 apply. Just as in [RFC6350], 624 truncation of the date part is permitted. 626 Example: 628 ... 629 ["anniversary", {}, "date-time", "2013-02-14T12:30:00"], 630 ["anniversary", {}, "date-time", "2013-01-10T19:00:00Z"], 631 ["anniversary", {}, "date-time", "2013-08-15T09:45:00+01:00"], 632 ["anniversary", {}, "date-time", "---15T09:45:00+01:00"], 633 ... 635 This table contains possible conversions between the vCard DATE-TIME 636 format its jCard date-time. This information is to be seen as an 637 informative reference, the normative reference is [ISO.8601.2000] and 638 [ISO.8601.2004]: 640 +----------------+----------------------+---------------------------+ 641 | Representation | vCard | jCard | 642 +----------------+----------------------+---------------------------+ 643 | Complete | 19850412T232050 | 1985-04-12T23:20:50 | 644 | | | | 645 | Complete | 19850412T232050Z | 1985-04-12T23:20:50Z | 646 | | | | 647 | Complete | 19850412T232050+0400 | 1985-04-12T23:20:50+04:00 | 648 | | | | 649 | Complete | 19850412T232050+04 | 1985-04-12T23:20:50+04 | 650 | | | | 651 | Reduced | 19850412T2320 | 1985-04-12T23:20 | 652 | | | | 653 | Reduced | 19850412T23 | 1985-04-12T23 | 654 | | | | 655 | Truncated and | --0412T2320 | --04-12T23:20 | 656 | Reduced | | | 657 | | | | 658 | Truncated and | --04T2320 | --04T23:20 | 659 | Reduced | | | 660 | | | | 661 | Truncated and | ---12T2320 | ---12T23:20 | 662 | Reduced | | | 663 | | | | 664 | Truncated and | --0412T2320 | --04-12T23:20 | 665 | Reduced | | | 666 | | | | 667 | Truncated and | --04T23 | --04T23 | 668 | Reduced | | | 669 +----------------+----------------------+---------------------------+ 671 As specified in [ISO.8601.2000], the date component shall not be 672 represented with reduced accuracy and the time component shall not be 673 truncated. Also, all combinations may have any zone designator 674 appended, as in the complete representation. 676 3.5.6. Date and/or Time (RFC6350 Section 4.3.4) 678 Description: vCard "DATE-AND-OR-TIME" property values are 679 represented by a property with the type identifier "date-and-or- 680 time". The value elements are either a date-time (Section 3.5.5), 681 a date (Section 3.5.3) or a time (Section 3.5.4) value. Just as 682 in [RFC6350] Section 4.3.4, a stand-alone time value MUST always 683 be preceded by a "T". 685 Example: 687 ... 688 ["bday", {}, "date-and-or-time", "2013-02-14T12:30:00"], 689 ["bday", {}, "date-and-or-time", "---22T14:00"] 690 ["bday", {}, "date-and-or-time", "1985"], 691 ["bday", {}, "date-and-or-time", "T12:30"], 692 ... 694 3.5.7. Timestamp (RFC6350 Section 4.3.5) 696 Description: vCard "TIMESTAMP" property values are represented by a 697 property with the type identifier "timestamp". The value elements 698 are JSON strings with the same timestamp value specified by 699 [RFC6350], but represented using the extended format and complete 700 representation specified in [ISO.8601.2004], Section 4.3.2. 702 Example: 704 ... 705 ["rev", {}, "timestamp", "2013-02-14T12:30:00"], 706 ["rev", {}, "timestamp", "2013-02-14T12:30:00Z"], 707 ["rev", {}, "timestamp", "2013-02-14T12:30:00-05"], 708 ["rev", {}, "timestamp", "2013-02-14T12:30:00-05:00"], 709 ... 711 This table contains possible conversions between the vCard TIMESTAMP 712 format its jCard timestamp. This information is to be seen as an 713 informative reference, the normative reference is [ISO.8601.2000] and 714 [ISO.8601.2004]: 716 +----------------+----------------------+---------------------------+ 717 | Representation | vCard | jCard | 718 +----------------+----------------------+---------------------------+ 719 | Complete | 19850412T232050 | 1985-04-12T23:20:50 | 720 | | | | 721 | Complete | 19850412T232050Z | 1985-04-12T23:20:50Z | 722 | | | | 723 | Complete | 19850412T232050+0400 | 1985-04-12T23:20:50+04:00 | 724 | | | | 725 | Complete | 19850412T232050+04 | 1985-04-12T23:20:50+04 | 726 +----------------+----------------------+---------------------------+ 728 3.5.8. Boolean (RFC6350 Section 4.4) 729 Description: vCard "BOOLEAN" property values are represented by a 730 property with the type identifier "boolean". The value element is 731 a JSON boolean value. 733 Example: 735 ... 736 ["x-non-smoking", {}, "boolean", true], 737 ... 739 3.5.9. Integer (RFC6350 Section 4.5) 741 Description: vCard "INTEGER" property values are represented by a 742 property with the type identifier "integer". The value elements 743 are JSON primitive number values. 745 Examples: 747 ... 748 ["x-karma-points", {}, "integer", 42], 749 ... 751 3.5.10. Float (RFC6350 Section 4.6) 753 Description: vCard "FLOAT" property values are represented by a 754 property with the type identifier "float". The value elements are 755 JSON primitive number values. 757 Example: 759 ... 760 ["x-grade", {}, "float", 1.3], 761 ... 763 3.5.11. UTC Offset (RFC6350 Section 4.7) 765 Description: vCard "UTC-OFFSET" property values are represented by a 766 property with the type identifier "utc-offset". The value 767 elements are JSON strings with the same UTC offset value specified 768 by [RFC6350], with the exception that the hour and minute 769 components are separated by a ":" character, for consistency with 770 the [ISO.8601.2004] timezone offset, extended format. 772 Example: 774 ... 775 // Note: [RFC6350] mentions use of utc-offset 776 // for the TZ property as NOT RECOMMENDED 777 ["tz", {}, "utc-offset", "-05:00"], 778 .. 780 3.5.12. Language Tag (RFC6350 Section 4.8) 782 Description: vCard "LANGUAGE-TAG" property values are represented by 783 a property with the type identifier "language-tag". The value 784 elements are JSON strings containing a single language-tag, as 785 defined in [RFC5646]. 787 Example: 789 ... 790 ["lang", {}, "language-tag", "de"], 791 .. 793 3.6. Extensions (RFC6350 Section 6.10) 795 vCard extension properties and property parameters (those with an 796 "X-" prefix in their name) are handled in the same way as other 797 properties and property parameters: the property is represented by an 798 array, the property parameter represented by an object. The property 799 or parameter name uses the same name as for the vCard extension, but 800 in lowercase. For example, the "X-FOO" property in vCard turns into 801 the "x-foo" jCard property. See Section 5 for how to deal with 802 default values for unrecognized extension properties or property 803 parameters. 805 4. Converting from jCard into vCard 807 When converting property and property parameter values, the names 808 SHOULD be converted to uppercase. Although vCard names are case 809 insensitive, common practice is to keep them all uppercase following 810 the actual definitions in [RFC6350]. 812 Backslash escaping and line folding MUST be applied to the resulting 813 vCard data as required by [RFC6350]. 815 When converting to vCard, the VALUE parameter MUST be added to 816 properties whose default value type is unknown. The VALUE parameter 817 SHOULD NOT be added to properties using the default value type. 819 5. Handling Unrecognized Properties or Parameters 821 In vCard, properties have a default value type specified by their 822 definition, e.g. "BDAY"'s value type is "date-and-or-time", but it 823 can also be reset to a single "text" value. When a property uses its 824 default value type, the "VALUE" property parameter does not need to 825 be specified on the property. 827 When new properties are defined or "X-" properties used, a vCard to 828 jCard converter might not recognize them, and not know what the 829 appropriate default value types are, yet they need to be able to 830 preserve the values. A similar issue arises for unrecognized 831 property parameters. 833 In jCard, a new UNKNOWN property value type is introduced. Its 834 purpose is to allow preserving unknown property values when round- 835 tripping between jCard and vCard. 837 Value name: UNKNOWN 839 Purpose: To allow preserving unknown property values during round- 840 tripping 842 Format definition: (Not applicable) 844 Description: The UNKNOWN value data type is reserved for the 845 exclusive use of the jCard format RFCTODO. It MUST NOT be used in 846 plain vCard [RFC6350]. Conversion rules are as follows: 848 * When converting vCard into jCard: 850 + Any property that does not include a "VALUE" property 851 parameter and whose default value type is not known, MUST be 852 converted to a primitive JSON string. The content of that 853 string is the unprocessed value text. Also, value type MUST 854 be set to "unknown". 856 + To correctly implement this format, it is critical that if 857 the default type is not known that the type "unknown" is 858 used. If this requirement is ignored and for example "text" 859 is used, additional escaping may occur which breaks round- 860 tripping values. 862 + Any unrecognized property parameter MUST be converted to a 863 string value, with its content set to the property parameter 864 value text, treated as if it were a "TEXT" value. 866 * When converting jCard into vCard: 868 + Since jCard always explicitly specifies the value type, it 869 can always be converted to vCard using the VALUE parameter. 871 + If the value type specified in jCard matches the default 872 value type in vCard, the VALUE parameter SHOULD be omitted. 874 + If the value type specified in jCard is set to "unknown", 875 the value MUST be taken over in vCard without processing. 876 In this case, the VALUE parameter MUST NOT be specified. 878 Example: The following is an example of an unrecognized vCard 879 property (that uses an "URI" value as its default), and the 880 equivalent jCard representation of that property. 882 vCard: 884 X-COMPLAINT-URI:mailto:abuse@example.org 886 jCard: 888 ... 889 ["x-complaint-uri", {}, "unknown", "mailto:abuse@example.org"], 890 ... 892 Example: The following is an example of how to cope with jCard data 893 where the parser was unable to identify the type. Note how the 894 "unknown" value type is not added to the vCard data and escaping, 895 aside from standard JSON string escaping, is not processed. 897 jCard: 899 ... 900 ["x-coffee-data", {}, "unknown", "Stenophylla;Guinea\\,Africa"], 901 ... 903 vCard: 905 X-COFFEE-DATA:Stenophylla;Guinea\,Africa 907 Example: The following is an example of a jCard property (where the 908 corresponding vCard property uses a "INTEGER" value as its default), 909 and the equivalent vCard representation of that property. It is 910 assumed that the parser has knowledge of the default data type for 911 the "x-karma-points" property. 913 jCard: 915 ... 916 ["x-karma-points", {}, "integer", 95], 917 ... 919 vCard: 921 X-KARMA-POINTS:95 923 Example: The following is an example of an unrecognized vCard 924 property parameter (that uses a "FLOAT" value as its default) 925 specified on a recognized vCard property, and the equivalent jCard 926 representation of that property and property parameter. 928 vCard: 930 GENDER;X-PROBABILITY=0.8:M 932 jCard: 934 ... 935 ["gender", { "x-probability": "0.8" }, "text", "M"], 936 ... 938 6. Implementation Status (to be removed prior to publication as an RFC) 940 This section describes libraries known to implement this draft as per 941 [I-D.sheffer-running-code]. 943 1. ICAL.js - Philipp Kewisch, James Lal. A JavaScript parser for 944 iCalendar (rfc5545) 946 Source: https://github.com/mozilla-comm/ical.js/ 948 Maturity: alpha (for jCard) 950 Coverage: Currently geared towards jCal, therefore not all 951 formats are supported. Includes an online validator. (as 952 of rev 847c67c501, 2013-02-14) 954 Licensing: MPL, Mozilla Public License 2.0 956 2. Py Calendar - Cyrus Daboo. iCalendar/vCard Library 957 Source: https://svn.calendarserver.org/repository/calendarserver 958 /PyCalendar/branches/json/ 960 Maturity: production 962 Coverage: All aspects of this draft, up to version 01. 964 Licensing: Apache License, Version 2.0 966 3. ez-vcard - Michael Angstadt. A vCard parser library written in 967 Java 969 Source: https://code.google.com/p/ez-vcard/ 971 Maturity: production 973 Coverage All aspects of this draft. 975 Licensing: New BSD License 977 Additionally, interoperability testing of this draft is an ongoing 978 effort under members of calconnect, the Calendaring and Scheduling 979 Consortium. CalDAV Vendors are looking into supporting this draft. 981 7. Security Considerations 983 For security considerations specific to calendar data, see Section 9 984 of [RFC6350]. Since this specification is a mapping from vCard, no 985 new security concerns are introduced related to calendar data. 987 The use of JSON as a format does have security risks. Section 7 of 988 [RFC4627] discusses these risks. 990 8. IANA Considerations 992 This document defines a MIME media type for use with vCard in JSON 993 data. This media type SHOULD be used for the transfer of calendaring 994 data in JSON. 996 Type name: application 998 Subtype name: vcard+json 1000 Required parameters: none 1002 Optional parameters: version as defined for the text/vcard media 1003 type in [RFC6350]. 1005 Encoding considerations: Same as encoding considerations of 1006 application/json as specified in [RFC4627]. 1008 Security considerations: See Section 7. 1010 Interoperability considerations: This media type provides an 1011 alternative format for vCard data based on JSON. 1013 Published specification: This specification. 1015 Applications which use this media type: Applications that currently 1016 make use of the text/vcard media type can use this as an 1017 alternative. Similarly, Applications that use the application/ 1018 json media type to transfer directory data can use this to further 1019 specify the content. 1021 Person & email address to contact for further information: 1022 vcarddav@ietf.org 1024 Intended usage: COMMON 1026 Restrictions on usage: There are no restrictions on where this media 1027 type can be used. 1029 Author: See the "Author's Address" section of this document. 1031 Change controller: IETF 1033 8.1. GROUP vCard Parameter 1035 IANA has added the following entry to the vCard Parameters registry, 1036 defined in Section 10.3.2 of [RFC6350]. 1038 +-----------+-----------+--------------------------+ 1039 | Namespace | Parameter | Reference | 1040 +-----------+-----------+--------------------------+ 1041 | | GROUP | RFCTODO, Section 3.3.1.2 | 1042 +-----------+-----------+--------------------------+ 1044 8.2. UNKNOWN vCard Value Data Type 1046 IANA has added the following entry to the vCard Data Types registry, 1047 defined in Section 10.3.3 of [RFC6350]. 1049 +-----------------+--------------------+ 1050 | Value Data Type | Reference | 1051 +-----------------+--------------------+ 1052 | UNKNOWN | RFCTODO, Section 5 | 1053 +-----------------+--------------------+ 1055 9. Acknowledgments 1057 The author would like to thank the following for their valuable 1058 contributions: Cyrus Daboo, Mike Douglass, William Gill, Erwin Rehme, 1059 and Dave Thewlis. Simon Perreault, Michael Angstadt, Peter Saint- 1060 Andre, Bert Greevenbosch, Javier Godoy. This specification 1061 originated from the work of the XML-JSON technical committee of the 1062 Calendaring and Scheduling Consortium. 1064 10. References 1066 10.1. Normative References 1068 [I-D.ietf-jcardcal-jcal] 1069 Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 1070 format for iCalendar", draft-ietf-jcardcal-jcal-00 (work 1071 in progress), March 2013. 1073 [ISO.8601.2000] 1074 International Organization for Standardization, ""Data 1075 elements and interchange formats -- Information 1076 interchange -- Representation of dates and times" ", ISO 1077 8601, 12 2000. 1079 [ISO.8601.2004] 1080 International Organization for Standardization, ""Data 1081 elements and interchange formats -- Information 1082 interchange -- Representation of dates and times" ", ISO 1083 8601, 12 2004. 1085 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1086 Requirement Levels", BCP 14, RFC 2119, March 1997. 1088 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1089 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1091 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 1092 Core Object Specification (iCalendar)", RFC 5545, 1093 September 2009. 1095 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1096 Languages", BCP 47, RFC 5646, September 2009. 1098 [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML 1099 Format for iCalendar", RFC 6321, August 2011. 1101 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 1102 August 2011. 1104 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 1105 6351, August 2011. 1107 10.2. Informative References 1109 [I-D.sheffer-running-code] 1110 Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1111 Code: the Implementation Status Section", draft-sheffer- 1112 running-code-02 (work in progress), January 2013. 1114 [RFC4627] Crockford, D., "The application/json Media Type for 1115 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1117 [calconnect-artifacts] 1118 The Calendaring and Scheduling Consortium, "Code Artifacts 1119 and Schemas", , 1120 . 1122 Appendix A. ABNF Schema 1124 Below is an ABNF schema as per [RFC5234] for vCard in JSON. ABNF 1125 Symbols not described here are taken from [RFC4627]. The schema is 1126 non-normative and given for reference only. 1128 The numeric section numbers given in the comments refer to section in 1129 [RFC6350]. Additional semantic restrictions apply, especially 1130 regarding the allowed properties and sub-components per component. 1131 Details on these restrictions can be found in this document and 1132 [RFC6350]. 1134 Additional schemas may be available on the internet at 1135 [calconnect-artifacts]. 1137 ; A vCard Stream is an array with the first element being the 1138 ; string "vcardstream". All remaining elements are jcardobjects. 1139 jcardstream = begin-array 1140 DQUOTE "vcardstream" DQUOTE 1141 *(value-separator jcardobject) 1142 end-array 1144 jcardobject = component 1145 ; A jCard object consists of the name string "vcard" and a properties 1146 ; array. Restrictions to which properties and may be specified are to 1147 ; be taken from RFC6350. 1148 jcardobject = begin-array 1149 DQUOTE component-name DQUOTE value-separator 1150 properties-array 1151 end-array 1153 ; A jCard property consists of the name string, parameters object, 1154 ; type string and one or more values as specified in this document. 1155 property = begin-array 1156 DQUOTE property-name DQUOTE value-separator 1157 params-object value-separator 1158 DQUOTE type-name DQUOTE 1159 propery-value *(value-separator property-value) 1160 end-array 1161 properties-array = begin-array 1162 [ property *(value-separator property) ] 1163 end-array 1165 ; Property values depend on the type-name. Aside from the value types 1166 ; mentioned here, extensions may make use of other JSON value types. 1167 property-value = simple-prop-value / structured-prop-value 1168 simple-prop-value = string / number / boolean 1169 structured-prop-value = 1170 begin-array 1171 [ structured-element *(value-separator structured-element) ] 1172 end-array 1174 ; Each structured element may have multiple values if 1175 ; semantically allowed 1176 structured-element = simple-prop-value / structured-multi-prop 1177 structured-multi-prop = 1178 begin-array 1179 [ simple-prop-value *(value-separator simple-prop-value) ] 1180 end-array 1182 ; The jCard params-object is a JSON object which follows the semantic 1183 ; guidelines described in this document. 1184 params-object = begin-object 1185 [ params-member *(value-separator params-member) ] 1186 end-object 1187 params-member = DQUOTE param-name DQUOTE name-separator param-value 1188 param-value = string / param-multi 1189 param-multi = begin-array 1190 [ string *(value-separtor string) ] 1191 end-array 1193 ; The type MUST be a valid type as described by this document. New 1194 ; value types can be added by extensions. 1195 type-name = "text" / "uri" / "date" / "time" / "date-time" / 1196 "boolean" / "integer" / "float" / "utc-offset" / 1197 "language-tag" / x-type 1199 ; Property, parameter and type names MUST be lowercase. Additional 1200 ; semantic restrictions apply as described by this document and 1201 ; RFC6350. 1202 component-name = lowercase-name 1203 property-name = lowercase-name 1204 param-name = lowercase-name 1205 x-type = lowercase-name 1206 lowercase-name = 1*(%x61-7A / DIGIT / "-") 1208 Appendix B. Examples 1210 This section contains an example of a vCard object with its jCard 1211 representation. 1213 B.1. Example: vCard of the author of RFC6350 1215 B.1.1. vCard Data 1217 BEGIN:VCARD 1218 VERSION:4.0 1219 FN:Simon Perreault 1220 N:Perreault;Simon;;;ing. jr,M.Sc. 1221 BDAY:--0203 1222 ANNIVERSARY:20090808T1430-0500 1223 GENDER:M 1224 LANG;PREF=1:fr 1225 LANG;PREF=2:en 1226 ORG;TYPE=work:Viagenie 1227 ADR;TYPE=work:;Suite D2-630;2875 Laurier; 1228 Quebec;QC;G1V 2M2;Canada 1229 TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102 1230 TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501 1231 EMAIL;TYPE=work:simon.perreault@viagenie.ca 1232 GEO;TYPE=work:geo:46.772673,-71.282945 1233 KEY;TYPE=work;VALUE=uri: 1234 http://www.viagenie.ca/simon.perreault/simon.asc 1235 TZ:-0500 1236 URL;TYPE=home:http://nomis80.org 1237 END:VCARD 1239 B.1.2. jCard Data 1241 ["vcard", 1242 [ 1243 ["version", {}, "text", "4.0"], 1244 ["fn", {}, "text", "Simon Perreault"], 1245 ["n", 1246 {}, 1247 "text", 1248 ["Perreault", "Simon", "", "", ["ing. jr", "M.Sc."]] 1249 ], 1250 ["bday", {}, "date-and-or-time", "--02-03"], 1251 ["anniversary", 1252 {}, 1253 "date-and-or-time", 1254 "2009-08-08T14:30:00-05:00" 1255 ], 1256 ["gender", {}, "text", "M"], 1257 ["lang", { "pref": "1" }, "language-tag", "fr"], 1258 ["lang", { "pref": "2" }, "language-tag", "en"], 1259 ["org", { "type": "work" }, "text", "Viagenie"], 1260 ["adr", 1261 { "type": "work" }, 1262 "text", 1263 [ 1264 "", 1265 "Suite D2-630", 1266 "2875 Laurier", 1267 "Quebec", 1268 "QC", 1269 "G1V 2M2", 1270 "Canada" 1271 ] 1272 ], 1273 ["tel", 1274 { "type": ["work", "voice"], "pref": "1" }, 1275 "uri", 1276 "tel:+1-418-656-9254;ext=102" 1277 ], 1278 ["tel", 1279 { "type": ["work", "cell", "voice", "video", "text"] }, 1280 "uri", 1281 "tel:+1-418-262-6501" 1282 ], 1283 ["email", 1284 { "type": "work" }, 1285 "text", 1286 "simon.perreault@viagenie.ca" 1288 ], 1289 ["geo", { "type": "work" }, "uri", "geo:46.772673,-71.282945"], 1290 ["key", 1291 { "type": "work" }, 1292 "uri", 1293 "http://www.viagenie.ca/simon.perreault/simon.asc" 1294 ], 1295 ["tz", {}, "utc-offset", "-05:00"], 1296 ["url", { "type": "home" }, "uri", "http://nomis80.org"] 1297 ] 1298 ] 1300 Appendix C. Change History (to be removed prior to publication as an 1301 RFC) 1303 draft-kewisch-vcard-in-json-01 1305 * Added ABNF and improved references in date/time related 1306 sections 1308 * Changes to wording in "vCard Stream" section 1310 * Changes to wording about VALUE parameter when converting to 1311 vCard 1313 * Corrected missing "type" parameter and separator in example 1315 * Minor wording corrections 1317 draft-ietf-jcardcal-jcard-00 1319 * Pubication as a WG draft 1321 draft-ietf-jcardcal-jcard-01 1323 * Changed grouping syntax to use new GROUP parameter and added 1324 respective IANA section 1326 * Added timestamp and date-and-or-time types instead of 1327 converting them from date/time/date-time 1329 * Added a further sentence on preprocessing and escaping to 1330 clarify that JSON escaping must be used 1332 * Described how to handle structured text values and structured 1333 text components with multiple values. 1335 * Corrections and additions to the ABNF Section, adaptions to 1336 example 1338 draft-ietf-jcardcal-jcard-02 1340 * Made more clear that complete representation is not mandatory 1342 * Added sheffer-running-code section 1344 * Changed handling of unknown property parameter types 1346 * Minor corrections to sections regarding dates, fixing typos 1348 draft-ietf-jcardcal-jcard-03 1350 * Add LABEL property example and description 1352 * Added acknowledgements 1354 * More typos fixed 1356 Author's Address 1358 Philipp Kewisch 1359 Mozilla Corporation 1360 650 Castro Street, Suite 300 1361 Mountain View, CA 94041 1362 USA 1364 EMail: mozilla@kewis.ch 1365 URI: http://www.mozilla.org/