idnits 2.17.1 draft-ietf-jcardcal-jcard-06.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 (September 26, 2013) is 3864 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 4627 (Obsoleted by RFC 7158, RFC 7159) == 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 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 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 September 26, 2013 5 Expires: March 30, 2014 7 jCard: The JSON format for vCard 8 draft-ietf-jcardcal-jcard-06 10 Abstract 12 This specification defines "jCard", a JSON format for vCard data. 13 The vCard data format is a text format for representing and 14 exchanging information about individuals and other entities, for 15 example telephone numbers, email addresses, structured names and 16 delivery addresses. JSON is a lightweight, text-based, language- 17 independent data interchange format commonly used in internet 18 applications. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 30, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 56 3. Converting from vCard to jCard . . . . . . . . . . . . . . . 4 57 3.1. Pre-processing . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. jCard Object and Syntactic Entities (RFC6350 section 59 6.1.1 and 6.1.2) . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Properties (RFC6350 section 6) . . . . . . . . . . . . . 5 61 3.3.1. Special Cases for Properties . . . . . . . . . . . . 7 62 3.3.1.1. The VERSION Property . . . . . . . . . . . . . . 7 63 3.3.1.2. Grouping of Properties . . . . . . . . . . . . . 7 64 3.3.1.3. Structured Property Values . . . . . . . . . . . 8 65 3.4. Parameters (RFC6350 Section 5) . . . . . . . . . . . . . 10 66 3.4.1. VALUE parameter . . . . . . . . . . . . . . . . . . . 11 67 3.4.2. Multi-value Parameters . . . . . . . . . . . . . . . 11 68 3.5. Values (RFC6350 Section 4) . . . . . . . . . . . . . . . 12 69 3.5.1. Text (RFC6350 Section 4.1) . . . . . . . . . . . . . 12 70 3.5.2. URI (RFC6350 Section 4.2) . . . . . . . . . . . . . . 13 71 3.5.3. Date (RFC6350 Section 4.3.1) . . . . . . . . . . . . 13 72 3.5.4. Time (RFC6350 Section 4.3.2) . . . . . . . . . . . . 14 73 3.5.5. Date-Time (RFC6350 Section 4.3.3) . . . . . . . . . . 15 74 3.5.6. Date and/or Time (RFC6350 Section 4.3.4) . . . . . . 17 75 3.5.7. Timestamp (RFC6350 Section 4.3.5) . . . . . . . . . . 17 76 3.5.8. Boolean (RFC6350 Section 4.4) . . . . . . . . . . . . 18 77 3.5.9. Integer (RFC6350 Section 4.5) . . . . . . . . . . . . 18 78 3.5.10. Float (RFC6350 Section 4.6) . . . . . . . . . . . . . 18 79 3.5.11. UTC Offset (RFC6350 Section 4.7) . . . . . . . . . . 19 80 3.5.12. Language Tag (RFC6350 Section 4.8) . . . . . . . . . 19 81 3.6. Extensions (RFC6350 Section 6.10) . . . . . . . . . . . . 19 82 4. Converting from jCard into vCard . . . . . . . . . . . . . . 19 83 5. Handling Unrecognized Properties or Parameters . . . . . . . 20 84 5.1. Converting vCard into jCard . . . . . . . . . . . . . . . 21 85 5.2. Converting jCard into vCard . . . . . . . . . . . . . . . 21 86 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 21 87 6. Implementation Status (to be removed prior to publication as 88 an RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 8.1. GROUP vCard Parameter . . . . . . . . . . . . . . . . . . 25 92 8.2. UNKNOWN vCard Value Data Type . . . . . . . . . . . . . . 25 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 96 10.2. Informative References . . . . . . . . . . . . . . . . . 27 98 Appendix A. ABNF Schema . . . . . . . . . . . . . . . . . . . . 27 99 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 29 100 B.1. Example: vCard of the author of RFC6350 . . . . . . . . . 29 101 B.1.1. vCard Data . . . . . . . . . . . . . . . . . . . . . 29 102 B.1.2. jCard Data . . . . . . . . . . . . . . . . . . . . . 29 103 Appendix C. Change History (to be removed prior to publication 104 as an RFC) . . . . . . . . . . . . . . . . . . . . . 31 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 107 1. Introduction 109 The vCard data format [RFC6350] provides for the capture and exchange 110 of information normally stored within an address book or directory 111 application. The vCard format has gone through multiple revisions, 112 most recently vCard 4. 114 As certain similarities exist between vCard and the iCalendar data 115 format [RFC5545], there is also an effort to define a JSON-based data 116 format for calendar information called jCal [I-D.ietf-jcardcal-jcal] 117 that parallels the format defined in this specification. The term 118 JSON describes the JavaScript Object Notation defined in [RFC4627]. 120 The purpose of this specification is to define "jCard", a JSON format 121 for vCard data. One main advantage to using a JSON-based format over 122 the classic vCard format is easier processing for JavaScript based 123 widgets and libraries, especially in the scope of web-based 124 applications. 126 The key design considerations are essentially the same as those for 127 [I-D.ietf-jcardcal-jcal] and [RFC6321], that is: 129 Round-tripping (converting a vCard instance to jCard and back) 130 will give the same semantic result as the starting point. For 131 example, all components, properties and property parameters are 132 guaranteed to be preserved. 134 Ordering of elements and case of property and parameter names will 135 not necessarily be preserved. 137 The vCard data semantics are to be preserved, allowing a simple 138 consumer to easily browse the data in jCard. A full understanding 139 of vCard is still required in order to modify and/or fully 140 comprehend the directory data. 142 Extensions to the underlying vCard specification must not lead to 143 requiring an update to jCard. 145 2. Conventions Used in This Document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 The underlying format used for jCard is JSON. Consequently, the 152 terms "object" and "array" as well as the four primitive types 153 (strings, numbers, booleans, and null) are to be interpreted as 154 described in Section 1 of [RFC4627]. 156 Some examples in this document contain "partial" JSON documents used 157 for illustrative purposes. In these examples, three periods "..." 158 are used to indicate a portion of the document that has been removed 159 for compactness. 161 3. Converting from vCard to jCard 163 This section describes how vCard objects are converted to jCard using 164 a simple mapping between the vCard data model and JSON elements. 166 In [RFC6350], vCard objects are comprised of a set of "properties", 167 "parameters" and "values". The top level of a vCard object contains 168 "properties". A "property" has a "value" and a set of zero or more 169 "parameters". Each of these entities have a representation in jCard, 170 defined in the following sections. The representation of a vCard 171 object in JSON will be named "jCard object" throughout this document. 173 3.1. Pre-processing 175 vCard uses a line folding mechanism to limit lines of data to a 176 maximum line length (typically 75 octets) to ensure maximum 177 likelihood of preserving data integrity as it is transported via 178 various means (e.g., email) - see Section 3.2 of [RFC6350]. 180 vCard data uses an "escape" character sequence for text values and 181 property parameter values. See Section 3.4 of [RFC6350] as well as 182 [RFC6868]. 184 When converting from vCard to jCard, first vCard lines MUST be 185 unfolded. Afterwards, any vCard escaping MUST be unescaped. Finally 186 JSON escaping (e.g., for control characters) MUST be applied. 188 The reverse order applies when converting from jCard to vCard. 189 First, JSON escaping MUST be unescaped. Afterwards, vCard escaping 190 MUST be applied. Finally, long lines SHOULD be folded as described 191 in [RFC6350]. 193 One key difference in the formatting of values used in vCard and 194 jCard is that in jCard the specification uses date/time values 195 aligned with the extended format of [ISO.8601.2004], which is more 196 commonly used in internet applications that make use of the JSON 197 format. The sections of this document describing the various date 198 and time formats contain more information on the use of the complete 199 representation, reduced accuracy or truncated representation. 201 3.2. jCard Object and Syntactic Entities (RFC6350 section 6.1.1 and 202 6.1.2) 204 In [RFC6350] Section 6.1.1 and 6.1.2, the "BEGIN" and "END" 205 properties delimit a syntactic vCard entity. In jCard, each 206 syntactic entity is represented by an array with two elements and is 207 named "jCard object". The first element is the string "vcard", the 208 second element is an array of jCard properties as described in 209 Section 3.3, belonging to the entity. 211 Although [RFC6350] defines BEGIN and END to be properties, they MUST 212 NOT appear as properties of the jCard. Instead, the jCard object is 213 sufficient to define a vCard entity. When converting from jCard to 214 vCard, the BEGIN and END properties MUST be added to enclose the 215 properties of the jCard object. 217 Example: 219 ["vcard", [ 220 /* Add properties in place of this comment */ 221 ] 222 ] 224 Consumers of this format wishing to define content that can contain 225 multiple syntactic entities within the same JSON document can use a 226 simple JSON array, each element being a jCard object. 228 3.3. Properties (RFC6350 section 6) 230 Each individual vCard property is represented in jCard by an array 231 with three fixed elements, followed by one or more additional 232 elements, depending on if the property is a multi-value property as 233 described in Section 3.3 of [RFC6350]. 235 The array consists of the following fixed elements: 237 1. The name of the property, as a lowercase string. The vCard 238 format specifies that property names are case-insensitive, and 239 recommends that they be rendered in uppercase. In jCard, they 240 MUST be in lowercase. 242 2. An object containing the parameters as described in Section 3.4. 243 If the property has no parameters, an empty object is used to 244 represent that. 246 3. The type identifier string of the value, in lowercase. It is 247 important that parsers check this to determine the data type of 248 the value, and that they do not rely on assumptions. For 249 example, for structured values the data type will be "array". 251 The remaining elements of the array are used for one or more values 252 of the property. For single-value properties, the array has exactly 253 four elements; for multi-valued properties, each value is another 254 element, and there can be any number of additional elements. 256 Single-valued properties example: 258 ["vcard", 259 [ 260 ["version", {}, "text", "4.0"], 261 ["fn", {}, "text", "John Doe"], 262 ["gender", {}, "text", "M"], 263 ... 264 ] 265 ] 267 Multi-valued property example: 269 ["vcard", 270 [ 271 ["categories", {}, "text", "computers", "cameras"], 272 ... 273 ] 274 ] 276 As described in Section 3.3.1.3, a property value may be a structured 277 property value, in which case it is represented as an array 278 encapsulated in the array that represents the overall property. 280 Strictly speaking, this means that the property value is not 281 represented in the format indicated by the type identifier, but by an 282 array instead. However, the values inside the encapsulated array are 283 of the format identified by the type identifier. 285 The above also holds for multi-valued properties, where some of the 286 values may be structured property values, and therefore are 287 represented as an encapsulated array. 289 A special case is where a value in an encapsulated array consists of 290 multiple components itself, in which case it is represented as yet 291 another nested array, with elements matching the value type. 292 Section 3.3.1.3 describes this in more detail. 294 The above illustrates the importance for the parser to check the 295 format of each property value, as it might either directly match the 296 value type, or it might be a structured value where nested sub- 297 elements match the value type. 299 3.3.1. Special Cases for Properties 301 This section describes some properties that have special handling 302 when converting to jCard. 304 3.3.1.1. The VERSION Property 306 The vCard format specification [RFC6350] defines the VERSION property 307 to be mandatory. The "version" property MUST be represented in the 308 corresponding jCard component, with the same value as in the vCard. 309 vCards that conform to RFC 6350 will contain the value "4.0". 311 Also in accordance to [RFC6350], the "version" property MUST be the 312 first element of the array containing the properties of a jCard. 314 3.3.1.2. Grouping of Properties 316 In vCard [RFC6350] related properties can be grouped together using a 317 grouping construct. The grouping is accomplished by adding a prefix 318 to the property name, which consists of the group name followed by a 319 dot. 321 In jCard the same grouping is achieved through a "group" parameter, 322 that holds the group name. In jCard a property name therefore MUST 323 NOT be prefixed by a group name. 325 The "GROUP" parameter MUST NOT be used in vCard as per [RFC6350] it 326 is merely registered to reserve the parameter, avoiding collisions. 328 Namespace: 330 Parameter name: GROUP 332 Purpose: To simplify the jCard format. 334 Description: The GROUP parameter is reserved for the exclusive use 335 of the jCard format described in this document. It MUST NOT be 336 used in plain vCard [RFC6350], nor in xCard [RFC6351]. 338 Format definition: (Not applicable) 340 Example: As this registration serves as a reservation of the GROUP 341 parameter so that it is not used in vCard, there is no applicable 342 vCard example. Examples of its usage in jCard can be found in 343 this document. 345 3.3.1.2.1. Group Conversion Rules 347 In jCard, the parameter's value is a single opaque string. 348 Conversion rules are as follows: 350 o From vCard to jCard, the group construct (see [RFC6350], 351 Section 3.3, Page 7) is removed. In its place, the "group" 352 parameter is used. Its value is a string corresponding to the 353 group name. The name's case MUST be preserved. 355 o When converting from jCard to vCard, the value of the "group" 356 parameter followed by a dot is prefixed to the property name, and 357 the "group" parameter is discarded. The "GROUP" parameter MUST 358 NOT appear in the resulting vCard. 360 Example: 362 CONTACT.FN:Mr. John Q. Public\, Esq. 364 is equivalent to: 366 [ "fn", { "group": "CONTACT" }, "text", "Mr. John Q. Public, Esq." ] 368 3.3.1.3. Structured Property Values 370 The vCard specification defines properties with structured values, 371 for example GENDER or ADR. In vCard, a structured text value 372 consists of one or multiple text components, delimited by the 373 SEMICOLON character. Its equivalent in jCard is a structured 374 property value, which is an array containing one element for each 375 text component, with empty/missing text components represented by 376 zero-length strings. 378 vCard Example: 380 ADR:;;123 Main Street;Any Town;CA;91921-1234;U.S.A. 382 jCard Example: 384 ["adr", {}, "text", 385 [ 386 "", "", "123 Main Street", 387 "Any Town", "CA", "91921-1234", "U.S.A." 388 ] 389 ] 391 Some vCard properties, for example ADR, also allow a structured value 392 element that itself has multiple values. In this case, the element 393 of the array describing the structured value is itself an array with 394 one element for each of the component's multiple values. 396 vCard Example: 398 ADR:;;My Street,Left Side,Second Shack;Hometown;PA;18252;U.S.A. 400 jCard Example: 402 ["adr", {}, "text", 403 [ 404 "", "", 405 ["My Street", "Left Side", "Second Shack"], 406 "Hometown", "PA", "18252", "U.S.A." 407 ] 408 ] 410 In both cases, the array element values MUST have the primitive type 411 that matches the jCard type identifier. In [RFC6350], there are only 412 structured text values and thus only JSON strings are used. 413 Extensions may for example define structured number or boolean 414 values, where JSON number or boolean types MUST be used. 416 Although it is allowed for a structured property value to hold just 417 one component, it is RECOMMENDED to represent it as a single text 418 value instead, omitting the array completely. Nevertheless, a simple 419 implementation MAY choose to retain the array, with a single text 420 value as its element. 422 Similarly, structured values that consist of two text components with 423 one being optional (for example, GENDER) can be represented as a 424 single text value. Therefore, parsers of jCard data SHOULD check 425 even known property values for structured information by considering 426 the JSON data type of the value, which can be an array or a primitive 427 value. This is especially important for languages where accessing 428 array members is done by the same construct as accessing characters 429 of a string. 431 Examples: 433 ["gender", {}, "text", ["F", "grrrl"] ], 434 ["gender", {}, "text", "M" ] 436 Per [RFC6350] Section 6.3.1, the component separator MUST be 437 specified even if the component value is missing. Similarly, the 438 jCard array containing the structured data MUST contain all required 439 elements, even if they are empty. 441 vCard Example: 443 ADR;LABEL="123 Maple Ave\nSuite 901\nVancouver BC\nA1B 2C9\nCan 444 ada":;;;;;; 446 jCard Example: 448 ["adr", 449 {"label":"123 Maple Ave\nSuite 901\nVancouver BC\nA1B 2C9\nCanada"}, 450 "text", 451 ["", "", "", "", "", "", ""] 452 ] 454 3.4. Parameters (RFC6350 Section 5) 456 Property parameters are represented as a JSON object where each key- 457 value pair represents the vCard parameter name and its value. The 458 name of the parameter MUST be in lowercase, the original case of the 459 parameter value MUST be preserved. For example, the "LANG" property 460 parameter is represented in jCard by the "lang" key. Any new vCard 461 parameters added in the future will be converted in the same way. 463 Example: 465 ["vcard", 466 [ 467 ["role", { "lang": "tr" }, "text", "roca"], 468 ... 469 ] 470 ] 472 3.4.1. VALUE parameter 474 vCard defines a "VALUE" property parameter (Section 5.2 of 475 [RFC6350]). This property parameter MUST NOT be added to the 476 parameters object. Instead, the value type is signaled through the 477 type identifier in the third element of the array describing the 478 property. When converting a property from vCard to jCard, the value 479 type is determined as follows: 481 1. If the property has a "VALUE" parameter, that parameter's value 482 is used as the value type. 484 2. If the property has no "VALUE" parameter but has a default value 485 type, the default value type is used. 487 3. If the property has no "VALUE" parameter and has no default value 488 type, "unknown" is used. 490 Converting from jCard into vCard is done as follows: 492 1. If the property's value type is "unknown", no "VALUE" parameter 493 is included. 495 2. If the property's value type is the default type for that 496 property, no "VALUE" parameter is included. 498 3. Otherwise, a "VALUE" parameter is included, and the value type is 499 used as the parameter value. 501 See Section 5 for information on handling unknown value types. 503 3.4.2. Multi-value Parameters 505 In [RFC6350], some parameters allow using a COMMA-separated list of 506 values. To ease processing in jCard, the value to such parameters 507 MUST be represented in an array containing the separated values. The 508 array elements MUST be string values. Single-value parameters SHOULD 509 be represented using a single string value, although a more simple 510 implementation might prefer an array with one string element. An 511 example for a such parameter is the vCard "SORT-AS" parameter, more 512 such parameters may be added in extensions. 514 The vCard specification requires encapsulation between DQUOTE 515 characters if a parameter value contains a colon, a semicolon or a 516 comma. These extra DQUOTE characters do not belong to the actual 517 parameter value, and hence are not included when the parameter is 518 converted to jCard. 520 Example: 522 ["vcard", 523 [ 524 ["n", 525 { "sort-as": ["Harten", "Rene"] }, 526 "text", 527 ["van der Harten", "Rene", "J.", "Sir", "R.D.O.N."] 528 ], 529 ["fn", {}, "text", "Rene van der Harten"] 530 ... 531 ] 532 ] 534 3.5. Values (RFC6350 Section 4) 536 The following subsections specify how vCard property value data 537 types, which are defined in the subsections of [RFC6350] Section 4, 538 are represented in jCard. 540 3.5.1. Text (RFC6350 Section 4.1) 542 Description: vCard "TEXT" property values are represented by a 543 property with the type identifier "text". The value elements are 544 JSON strings. For details on structured text values, see 545 Section 3.3.1.3. 547 Example: 549 ["kind", {}, "text", "group"] 551 3.5.2. URI (RFC6350 Section 4.2) 553 Description: vCard "URI" property values are represented by a 554 property with the type identifier "uri". The value elements are 555 JSON strings. 557 Example: 559 ["source", {}, "uri", "ldap://ldap.example.com/cn=babs%20jensen"] 561 3.5.3. Date (RFC6350 Section 4.3.1) 563 Description: vCard "DATE" property values are represented by a 564 property with the type identifier "date". The value elements are 565 JSON strings with the same date value specified by [RFC6350], but 566 represented using the extended format specified in 567 [ISO.8601.2004], Section 4.1.2. If the complete representation is 568 not used, the same date format restrictions regarding reduced 569 accuracy, truncated representation and expanded representation 570 noted in [RFC6350] Section 4.3.1 apply. Whenever the extended 571 format is not applicable, the basic format MUST be used. 573 ABNF Schema: 575 date-complete = year "-" month "-" day ;YYYY-MM-DD 577 date-noreduc = date-complete 578 / "--" month "-" day; --MM-DD 579 / "---" day; ---DDD 581 date = date-noreduc 582 / year; YYYY 583 / year "-" month ; YYYY-MM 584 / "--" month; --MM 586 Examples: 588 ["bday", {}, "date", "1985-04-12"], 589 ["bday", {}, "date", "1985-04"], 590 ["bday", {}, "date", "1985"], 591 ["bday", {}, "date", "--04-12"], 592 ["bday", {}, "date", "---12"] 594 This table contains possible conversions between the vCard DATE 595 format its jCard date. This information is just an example and not a 596 formal specification of the syntax. The specification can be found 597 in [ISO.8601.2000] and [ISO.8601.2004]: 599 +-----------+----------+------------+ 600 | | vCard | jCard | 601 +-----------+----------+------------+ 602 | Complete | 19850412 | 1985-04-12 | 603 | | | | 604 | Reduced | 1985-04 | 1985-04 | 605 | | | | 606 | Reduced | 1985 | 1985 | 607 | | | | 608 | Truncated | --0412 | --04-12 | 609 | | | | 610 | Truncated | --04 | --04 | 611 | | | | 612 | Truncated | ---12 | ---12 | 613 +-----------+----------+------------+ 615 3.5.4. Time (RFC6350 Section 4.3.2) 617 Description: vCard "TIME" property values are represented by a 618 property with the type identifier "time". The value elements are 619 JSON strings with the same time value specified by [RFC6350], but 620 represented using the extended format specified in 621 [ISO.8601.2004], Section 4.2. If the complete representation is 622 not used, the same time format restrictions regarding reduced 623 accuracy, decimal fraction and truncated representation noted in 624 [RFC6350] Section 4.3.2 apply. Whenever the extended format is 625 not applicable, the basic format MUST be used. The seconds value 626 of 60 MUST only be used to account for positive "leap" seconds and 627 the midnight hour is always represented by 00, never 24. 628 Fractions of a second are not supported by this format. In jCard, 629 UTC offsets are permitted within a time value; note that this 630 differs from jCal [I-D.ietf-jcardcal-jcal], where they are not 631 permitted. 633 ABNF Schema: 635 time-notrunc = hour [":" minute [":" second]] [zone] 637 time = time-notrunc 638 / "-" minute ":" second [zone]; -mm:ss 639 / "-" minute [zone]; -mm 640 / "--" second [zone]; --ss 642 Examples: 644 ["x-time-local", {}, "time", "12:30:00"], 645 ["x-time-utc", {}, "time", "12:30:00Z"], 646 ["x-time-offset", {}, "time", "12:30:00-08:00"], 647 ["x-time-reduced", {}, "time", "23"], 648 ["x-time-truncated", {}, "time", "-30"] 650 This table contains possible conversions between the vCard TIME 651 format its jCard time. This information is just an example and not a 652 formal specification of the syntax. The specification can be found 653 in [ISO.8601.2000] and [ISO.8601.2004]: 655 +-----------+--------+----------+ 656 | | vCard | jCard | 657 +-----------+--------+----------+ 658 | Complete | 232050 | 23:20:50 | 659 | | | | 660 | Reduced | 2320 | 23:20 | 661 | | | | 662 | Reduced | 23 | 23 | 663 | | | | 664 | Truncated | -2050 | -20:50 | 665 | | | | 666 | Truncated | -20 | -20 | 667 | | | | 668 | Truncated | --50 | --50 | 669 +-----------+--------+----------+ 671 Also, all combinations may have any zone designator appended, as in 672 the complete representation. 674 3.5.5. Date-Time (RFC6350 Section 4.3.3) 676 Description: vCard "DATE-TIME" property values are represented by a 677 property with the type identifier "date-time". The value elements 678 are JSON strings with the same date value specified by [RFC6350], 679 but represented using the extended format specified in 680 [ISO.8601.2004], Section 4.3. If the complete representation is 681 not used, the same date and time format restrictions as in 682 Section 3.5.4 and Section 3.5.3 apply. Just as in [RFC6350], 683 truncation of the date part is permitted. 685 Example: 687 ["anniversary", {}, "date-time", "2013-02-14T12:30:00"], 688 ["anniversary", {}, "date-time", "2013-01-10T19:00:00Z"], 689 ["anniversary", {}, "date-time", "2013-08-15T09:45:00+01:00"], 690 ["anniversary", {}, "date-time", "---15T09:45:00+01:00"] 692 This table contains possible conversions between the vCard DATE-TIME 693 format its jCard date-time. This information is just an example and 694 not a formal specification of the syntax. The specification can be 695 found in [ISO.8601.2000] and [ISO.8601.2004]: 697 +----------------+----------------------+---------------------------+ 698 | Representation | vCard | jCard | 699 +----------------+----------------------+---------------------------+ 700 | Complete | 19850412T232050 | 1985-04-12T23:20:50 | 701 | | | | 702 | Complete | 19850412T232050Z | 1985-04-12T23:20:50Z | 703 | | | | 704 | Complete | 19850412T232050+0400 | 1985-04-12T23:20:50+04:00 | 705 | | | | 706 | Complete | 19850412T232050+04 | 1985-04-12T23:20:50+04 | 707 | | | | 708 | Reduced | 19850412T2320 | 1985-04-12T23:20 | 709 | | | | 710 | Reduced | 19850412T23 | 1985-04-12T23 | 711 | | | | 712 | Truncated and | --0412T2320 | --04-12T23:20 | 713 | Reduced | | | 714 | | | | 715 | Truncated and | --04T2320 | --04T23:20 | 716 | Reduced | | | 717 | | | | 718 | Truncated and | ---12T2320 | ---12T23:20 | 719 | Reduced | | | 720 | | | | 721 | Truncated and | --0412T2320 | --04-12T23:20 | 722 | Reduced | | | 723 | | | | 724 | Truncated and | --04T23 | --04T23 | 725 | Reduced | | | 726 +----------------+----------------------+---------------------------+ 728 As specified in [ISO.8601.2000], the date component shall not be 729 represented with reduced accuracy and the time component shall not be 730 truncated. Also, all combinations may have any zone designator 731 appended, as in the complete representation. 733 3.5.6. Date and/or Time (RFC6350 Section 4.3.4) 735 Description: vCard "DATE-AND-OR-TIME" property values are 736 represented by a property with the type identifier "date-and-or- 737 time". The value elements are either a date-time (Section 3.5.5), 738 a date (Section 3.5.3) or a time (Section 3.5.4) value. Just as 739 in [RFC6350] Section 4.3.4, a stand-alone time value MUST always 740 be preceded by a "T". 742 Example: 744 ["bday", {}, "date-and-or-time", "2013-02-14T12:30:00"], 745 ["bday", {}, "date-and-or-time", "---22T14:00"] 746 ["bday", {}, "date-and-or-time", "1985"], 747 ["bday", {}, "date-and-or-time", "T12:30"] 749 3.5.7. Timestamp (RFC6350 Section 4.3.5) 751 Description: vCard "TIMESTAMP" property values are represented by a 752 property with the type identifier "timestamp". The value elements 753 are JSON strings with the same timestamp value specified by 754 [RFC6350], but represented using the extended format and complete 755 representation specified in [ISO.8601.2004], Section 4.3.2. 757 Example: 759 ["rev", {}, "timestamp", "2013-02-14T12:30:00"], 760 ["rev", {}, "timestamp", "2013-02-14T12:30:00Z"], 761 ["rev", {}, "timestamp", "2013-02-14T12:30:00-05"], 762 ["rev", {}, "timestamp", "2013-02-14T12:30:00-05:00"] 764 This table contains possible conversions between the vCard TIMESTAMP 765 format its jCard timestamp. This information is just an example and 766 not a formal specification of the syntax. The specification can be 767 found in [ISO.8601.2000] and [ISO.8601.2004]: 769 +----------------+----------------------+---------------------------+ 770 | Representation | vCard | jCard | 771 +----------------+----------------------+---------------------------+ 772 | Complete | 19850412T232050 | 1985-04-12T23:20:50 | 773 | | | | 774 | Complete | 19850412T232050Z | 1985-04-12T23:20:50Z | 775 | | | | 776 | Complete | 19850412T232050+0400 | 1985-04-12T23:20:50+04:00 | 777 | | | | 778 | Complete | 19850412T232050+04 | 1985-04-12T23:20:50+04 | 779 +----------------+----------------------+---------------------------+ 781 3.5.8. Boolean (RFC6350 Section 4.4) 783 Description: vCard "BOOLEAN" property values are represented by a 784 property with the type identifier "boolean". The value element is 785 a JSON boolean value. 787 Example: 789 ["x-non-smoking", {}, "boolean", true] 791 3.5.9. Integer (RFC6350 Section 4.5) 793 Description: vCard "INTEGER" property values are represented by a 794 property with the type identifier "integer". The value elements 795 are JSON primitive number values. 797 Examples: 799 ["x-karma-points", {}, "integer", 42] 801 Neither JSON nor jCard prohibits using a combination of decimals and 802 exponents to form an integer number. However, since vCard does not 803 support decimals or exponents in integers, any decimals and exponents 804 MUST be eliminated when converting an "integer" value type property 805 from jCard to vCard. 807 3.5.10. Float (RFC6350 Section 4.6) 809 Description: vCard "FLOAT" property values are represented by a 810 property with the type identifier "float". The value elements are 811 JSON primitive number values. 813 Example: 815 ["x-grade", {}, "float", 1.3] 817 Neither JSON nor jCard prohibits using exponents to form a float 818 number. However, since vCard does not support exponents in floats, 819 any exponents MUST be eliminated when converting a "float" value type 820 property from jCard to vCard. 822 3.5.11. UTC Offset (RFC6350 Section 4.7) 824 Description: vCard "UTC-OFFSET" property values are represented by a 825 property with the type identifier "utc-offset". The value 826 elements are JSON strings with the same UTC offset value specified 827 by [RFC6350], with the exception that the hour and minute 828 components are separated by a ":" character, for consistency with 829 the [ISO.8601.2004] timezone offset, extended format. 831 Example: 833 // Note: [RFC6350] mentions use of utc-offset 834 // for the TZ property as NOT RECOMMENDED 835 ["tz", {}, "utc-offset", "-05:00"] 837 3.5.12. Language Tag (RFC6350 Section 4.8) 839 Description: vCard "LANGUAGE-TAG" property values are represented by 840 a property with the type identifier "language-tag". The value 841 elements are JSON strings containing a single language-tag, as 842 defined in [RFC5646]. 844 Example: 846 ["lang", {}, "language-tag", "de"] 848 3.6. Extensions (RFC6350 Section 6.10) 850 vCard extension properties and property parameters (those with an 851 "X-" prefix in their name) are handled in the same way as other 852 properties and property parameters: the property is represented by an 853 array, the property parameter represented by an object. The property 854 or parameter name uses the same name as for the vCard extension, but 855 in lowercase. For example, the "X-FOO" property in vCard turns into 856 the "x-foo" jCard property. See Section 5 for how to deal with 857 default values for unrecognized extension properties or property 858 parameters. 860 4. Converting from jCard into vCard 862 When converting property and property parameter values, the names 863 SHOULD be converted to uppercase. Although vCard names are case 864 insensitive, common practice is to keep them all uppercase following 865 the actual definitions in [RFC6350]. 867 Character escaping and line folding MUST be applied to the resulting 868 vCard data as required by [RFC6350] and [RFC6868]. 870 When converting to vCard, the VALUE parameter MUST be added to 871 properties whose default value type is unknown. The VALUE parameter 872 MAY be omitted for properties using the default value type. 874 5. Handling Unrecognized Properties or Parameters 876 In vCard, properties can have one or more value types as specified by 877 their definition, with one of those values being defined as the 878 default. When a property uses its default value type, the "VALUE" 879 property parameter does not need to be specified on the property. 880 For example, "BDAY"'s default value type is "date-and-or-time", so 881 "VALUE=date-and-or-time" need not be set as a property parameter. 882 However, "BDAY" also allows a "text" value to be specified, and if 883 that is used, "VALUE=text" has to be set as a property parameter. 885 When new properties are defined or "X-" properties used, a vCard to 886 jCard converter might not recognize them, and not know what the 887 appropriate default value types are, yet they need to be able to 888 preserve the values. A similar issue arises for unrecognized 889 property parameters. 891 In jCard, a new "unknown" property value type is introduced. Its 892 purpose is to allow preserving unknown property values when round- 893 tripping between jCard and vCard. To avoid collisions, this 894 specification reserves the UNKNOWN property value type in vCard. It 895 MUST NOT be used in any vCard as specified by [RFC6350], nor any 896 extensions to it. 898 Value name: UNKNOWN 900 Purpose: To allow preserving property values whose default value 901 type is not known during round-tripping between jCard and vCard. 903 Format definition: (Not applicable) 905 Description: The UNKNOWN value data type is reserved for the 906 exclusive use of the jCard format. It MUST NOT be used in plain 907 vCard [RFC6350]. 909 Example: As this registration serves as a reservation of the UNKNOWN 910 type so that it is not used in vCard, there is no applicable vCard 911 example. Examples of its usage in jCard can be found in this 912 document. 914 5.1. Converting vCard into jCard 916 Any property that does not include a "VALUE" property parameter and 917 whose default value type is not known, MUST be converted to a 918 primitive JSON string. The content of that string is the unprocessed 919 value text. Also, value type MUST be set to "unknown". 921 To correctly implement this format, it is critical that if the 922 default type is not known that the value type "unknown" is used. If 923 this requirement is ignored and for example "text" is used, 924 additional escaping may occur which breaks round-tripping values. 926 Any unrecognized property parameter MUST be converted to a string 927 value, with its content set to the property parameter value text, 928 treated as if it were a "TEXT" value. 930 5.2. Converting jCard into vCard 932 In jCard the value type is always explicitly specified. It is 933 converted to vCard using the vCard VALUE parameter, except in the 934 following two cases: 936 o If the value type specified in jCard matches the default value 937 type in vCard, the VALUE parameter MAY be omitted. 939 o If the value type specified in jCard is set to "unknown", the 940 VALUE parameter MUST NOT be specified. The value MUST be taken 941 over in vCard without processing. 943 5.3. Examples 945 The following is an example of an unrecognized vCard property (that 946 uses an "URI" value as its default), and the equivalent jCard 947 representation of that property. 949 vCard: 951 X-COMPLAINT-URI:mailto:abuse@example.org 953 jCard: 955 ["x-complaint-uri", {}, "unknown", "mailto:abuse@example.org"] 956 The following is an example of how to cope with jCard data where the 957 parser was unable to identify the value type. Note how the "unknown" 958 value type is not added to the vCard data and escaping, aside from 959 standard JSON string escaping, is not processed. 961 jCard: 963 ["x-coffee-data", {}, "unknown", "Stenophylla;Guinea\\,Africa"] 965 vCard: 967 X-COFFEE-DATA:Stenophylla;Guinea\,Africa 969 There are no standard properties in [RFC6350] that have a default 970 type of integer. Consequently, this example uses the following 971 extended property which we treat as having a default type known to 972 the parser, namely integer, in order to illustrate how a property 973 with a known default type would be transformed. 975 jCard: 977 ["x-karma-points", {}, "integer", 95] 979 vCard: 981 X-KARMA-POINTS:95 983 The following is an example of an unrecognized vCard property 984 parameter (that uses a "FLOAT" value as its default) specified on a 985 recognized vCard property, and the equivalent jCard representation of 986 that property and property parameter. 988 vCard: 990 GENDER;X-PROBABILITY=0.8:M 992 jCard: 994 ["gender", { "x-probability": "0.8" }, "text", "M"] 996 6. Implementation Status (to be removed prior to publication as an RFC) 997 This section describes libraries known to implement this draft as per 998 [I-D.sheffer-running-code]. 1000 1. ICAL.js - Philipp Kewisch, James Lal. A JavaScript parser for 1001 iCalendar (rfc5545) 1003 Source: https://github.com/mozilla-comm/ical.js/ 1005 Maturity: alpha (for jCard) 1007 Coverage: Currently geared towards jCal, therefore not all 1008 formats are supported. Includes an online validator. (as 1009 of rev 847c67c501, 2013-02-14) 1011 Licensing: MPL, Mozilla Public License 2.0 1013 2. Py Calendar - Cyrus Daboo. iCalendar/vCard Library 1015 Source: https://svn.calendarserver.org/repository/calendarserver 1016 /PyCalendar/branches/json/ 1018 Maturity: production 1020 Coverage: All aspects of this draft, up to version 01. 1022 Licensing: Apache License, Version 2.0 1024 3. ez-vcard - Michael Angstadt. A vCard parser library written in 1025 Java 1027 Source: https://code.google.com/p/ez-vcard/ 1029 Maturity: production 1031 Coverage All aspects of this draft. 1033 Licensing: New BSD License 1035 Additionally, interoperability testing of this draft is an ongoing 1036 effort under members of calconnect, the Calendaring and Scheduling 1037 Consortium. CalDAV Vendors are looking into supporting this draft. 1039 7. Security Considerations 1041 This specification defines how vCard data can be "translated" between 1042 two different data formats - the original text format and JSON - with 1043 a one-to-one mapping to ensure all the semantic data in one format 1044 (properties, parameters and values) are preserved in the other. It 1045 does not change the semantic meaning of the underlying data itself, 1046 or impose or remove any security considerations that apply to the 1047 underlying data. 1049 The use of JSON as a format does have its own inherent security risks 1050 as discussed in Section 7 of [RFC4627]. Even though JSON is 1051 considered a safe subset of JavaScript, it should be kept in mind 1052 that a flaw in the parser processing JSON could still impose a threat 1053 which doesn't arise with conventional vCard data. 1055 With this in mind, a parser for JSON data should be used for jCard 1056 that is aware of the security implications. For example, the use of 1057 JavaScript's eval() function is only allowed using the regular 1058 expression in Section 6 of [RFC4627]. A native parser with full 1059 awareness of the JSON format should be preferred. 1061 In addition, it is expected that this new format will result in vCard 1062 data being more widely disseminated (e.g., with use in web 1063 applications rather than just dedicated "contact managers"). 1065 In all cases, application developers have to conform to the semantics 1066 of the vCard data as defined by [RFC6350] and associated extensions, 1067 and all of the security considerations described in Section 9 of 1068 [RFC6350], or any associated extensions, are applicable. 1070 8. IANA Considerations 1072 This document defines a MIME media type for use with vCard in JSON 1073 data. This media type SHOULD be used for the transfer of calendaring 1074 data in JSON. 1076 Type name: application 1078 Subtype name: vcard+json 1080 Required parameters: none 1082 Optional parameters: version as defined for the text/vcard media 1083 type in [RFC6350]. 1085 Encoding considerations: Same as encoding considerations of 1086 application/json as specified in [RFC4627]. 1088 Security considerations: See Section 7. 1090 Interoperability considerations: This media type provides an 1091 alternative format for vCard data based on JSON. 1093 Published specification: This specification. 1095 Applications which use this media type: Applications that currently 1096 make use of the text/vcard media type can use this as an 1097 alternative. Similarly, Applications that use the application/ 1098 json media type to transfer directory data can use this to further 1099 specify the content. 1101 Fragment identifier considerations: N/A 1103 Additional information: 1105 Deprecated alias names for this type: N/A 1107 Magic number(s): N/A 1109 File extension(s): N/A 1111 Macintosh file type code(s): N/A 1113 Person & email address to contact for further information: 1114 vcarddav@ietf.org 1116 Intended usage: COMMON 1118 Restrictions on usage: There are no restrictions on where this media 1119 type can be used. 1121 Author: See the "Author's Address" section of this document. 1123 Change controller: IETF 1125 8.1. GROUP vCard Parameter 1127 IANA has added the following entry to the vCard Parameters registry, 1128 defined in Section 10.3.2 of [RFC6350]. 1130 +-----------+-----------+--------------------------+ 1131 | Namespace | Parameter | Reference | 1132 +-----------+-----------+--------------------------+ 1133 | | GROUP | RFCTODO, Section 3.3.1.2 | 1134 +-----------+-----------+--------------------------+ 1136 8.2. UNKNOWN vCard Value Data Type 1138 IANA has added the following entry to the vCard Data Types registry, 1139 defined in Section 10.3.3 of [RFC6350]. 1141 +-----------------+--------------------+ 1142 | Value Data Type | Reference | 1143 +-----------------+--------------------+ 1144 | UNKNOWN | RFCTODO, Section 5 | 1145 +-----------------+--------------------+ 1147 9. Acknowledgments 1149 The author would like to thank the following for their valuable 1150 contributions: Cyrus Daboo, Mike Douglass, William Gill, Erwin Rehme, 1151 and Dave Thewlis. Simon Perreault, Michael Angstadt, Peter Saint- 1152 Andre, Bert Greevenbosch, Javier Godoy. This specification 1153 originated from the work of the XML-JSON technical committee of the 1154 Calendaring and Scheduling Consortium. 1156 10. References 1158 10.1. Normative References 1160 [ISO.8601.2000] 1161 International Organization for Standardization, ""Data 1162 elements and interchange formats -- Information 1163 interchange -- Representation of dates and times" ", ISO 1164 8601, 12 2000. 1166 [ISO.8601.2004] 1167 International Organization for Standardization, ""Data 1168 elements and interchange formats -- Information 1169 interchange -- Representation of dates and times" ", ISO 1170 8601, 12 2004. 1172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1173 Requirement Levels", BCP 14, RFC 2119, March 1997. 1175 [RFC4627] Crockford, D., "The application/json Media Type for 1176 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1178 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1179 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1181 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1182 Languages", BCP 47, RFC 5646, September 2009. 1184 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 1185 August 2011. 1187 [RFC6868] Daboo, C., "Parameter Value Encoding in iCalendar and 1188 vCard", RFC 6868, February 2013. 1190 10.2. Informative References 1192 [I-D.ietf-jcardcal-jcal] 1193 Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 1194 format for iCalendar", draft-ietf-jcardcal-jcal-00 (work 1195 in progress), March 2013. 1197 [I-D.sheffer-running-code] 1198 Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1199 Code: the Implementation Status Section", draft-sheffer- 1200 running-code-02 (work in progress), January 2013. 1202 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 1203 Core Object Specification (iCalendar)", RFC 5545, 1204 September 2009. 1206 [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML 1207 Format for iCalendar", RFC 6321, August 2011. 1209 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 1210 6351, August 2011. 1212 [calconnect-artifacts] 1213 The Calendaring and Scheduling Consortium, "Code Artifacts 1214 and Schemas", , 1215 . 1217 Appendix A. ABNF Schema 1219 Below is an ABNF schema as per [RFC5234] for vCard in JSON. ABNF 1220 Symbols not described here are taken from [RFC4627]. The schema is 1221 non-normative and given for reference only. 1223 The numeric section numbers given in the comments refer to section in 1224 [RFC6350]. Additional semantic restrictions apply, especially 1225 regarding the allowed properties and sub-components per component. 1226 Details on these restrictions can be found in this document and 1227 [RFC6350]. 1229 Additional schemas may be available on the internet at 1230 [calconnect-artifacts]. 1232 ; A jCard object uses the name "vcard" and a properties array. 1233 ; Restrictions to which properties and may be specified are to 1234 ; be taken from RFC6350. 1236 jcardobject = begin-array 1237 DQUOTE component-name DQUOTE value-separator 1238 properties-array 1239 end-array 1241 ; A jCard property consists of the name string, parameters object, 1242 ; type string and one or more values as specified in this document. 1243 property = begin-array 1244 DQUOTE property-name DQUOTE value-separator 1245 params-object value-separator 1246 DQUOTE type-name DQUOTE 1247 propery-value *(value-separator property-value) 1248 end-array 1249 properties-array = begin-array 1250 [ property *(value-separator property) ] 1251 end-array 1253 ; Property values depend on the type-name. Aside from the value types 1254 ; mentioned here, extensions may make use of other JSON value types. 1255 property-value = simple-prop-value / structured-prop-value 1256 simple-prop-value = string / number / true / false 1257 structured-prop-value = 1258 begin-array 1259 [ structured-element *(value-separator structured-element) ] 1260 end-array 1262 ; Each structured element may have multiple values if 1263 ; semantically allowed 1264 structured-element = simple-prop-value / structured-multi-prop 1265 structured-multi-prop = 1266 begin-array 1267 [ simple-prop-value *(value-separator simple-prop-value) ] 1268 end-array 1270 ; The jCard params-object is a JSON object which follows the semantic 1271 ; guidelines described in this document. 1272 params-object = begin-object 1273 [ params-member *(value-separator params-member) ] 1274 end-object 1275 params-member = DQUOTE param-name DQUOTE name-separator param-value 1276 param-value = string / param-multi 1277 param-multi = begin-array 1278 [ string *(value-separtor string) ] 1279 end-array 1281 ; The type MUST be a valid type as described by this document. New 1282 ; value types can be added by extensions. 1283 type-name = "text" / "uri" / "date" / "time" / "date-time" / 1284 "boolean" / "integer" / "float" / "utc-offset" / 1285 "language-tag" / x-type 1287 ; Property, parameter and type names MUST be lowercase. Additional 1288 ; semantic restrictions apply as described by this document and 1289 ; RFC6350. 1290 component-name = lowercase-name 1291 property-name = lowercase-name 1292 param-name = lowercase-name 1293 x-type = lowercase-name 1294 lowercase-name = 1*(%x61-7A / DIGIT / "-") 1296 Appendix B. Examples 1298 This section contains an example of a vCard object with its jCard 1299 representation. 1301 B.1. Example: vCard of the author of RFC6350 1303 B.1.1. vCard Data 1305 BEGIN:VCARD 1306 VERSION:4.0 1307 FN:Simon Perreault 1308 N:Perreault;Simon;;;ing. jr,M.Sc. 1309 BDAY:--0203 1310 ANNIVERSARY:20090808T1430-0500 1311 GENDER:M 1312 LANG;PREF=1:fr 1313 LANG;PREF=2:en 1314 ORG;TYPE=work:Viagenie 1315 ADR;TYPE=work:;Suite D2-630;2875 Laurier; 1316 Quebec;QC;G1V 2M2;Canada 1317 TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102 1318 TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501 1319 EMAIL;TYPE=work:simon.perreault@viagenie.ca 1320 GEO;TYPE=work:geo:46.772673,-71.282945 1321 KEY;TYPE=work;VALUE=uri: 1322 http://www.viagenie.ca/simon.perreault/simon.asc 1323 TZ:-0500 1324 URL;TYPE=home:http://nomis80.org 1325 END:VCARD 1327 B.1.2. jCard Data 1329 ["vcard", 1331 [ 1332 ["version", {}, "text", "4.0"], 1333 ["fn", {}, "text", "Simon Perreault"], 1334 ["n", 1335 {}, 1336 "text", 1337 ["Perreault", "Simon", "", "", ["ing. jr", "M.Sc."]] 1338 ], 1339 ["bday", {}, "date-and-or-time", "--02-03"], 1340 ["anniversary", 1341 {}, 1342 "date-and-or-time", 1343 "2009-08-08T14:30:00-05:00" 1344 ], 1345 ["gender", {}, "text", "M"], 1346 ["lang", { "pref": "1" }, "language-tag", "fr"], 1347 ["lang", { "pref": "2" }, "language-tag", "en"], 1348 ["org", { "type": "work" }, "text", "Viagenie"], 1349 ["adr", 1350 { "type": "work" }, 1351 "text", 1352 [ 1353 "", 1354 "Suite D2-630", 1355 "2875 Laurier", 1356 "Quebec", 1357 "QC", 1358 "G1V 2M2", 1359 "Canada" 1360 ] 1361 ], 1362 ["tel", 1363 { "type": ["work", "voice"], "pref": "1" }, 1364 "uri", 1365 "tel:+1-418-656-9254;ext=102" 1366 ], 1367 ["tel", 1368 { "type": ["work", "cell", "voice", "video", "text"] }, 1369 "uri", 1370 "tel:+1-418-262-6501" 1371 ], 1372 ["email", 1373 { "type": "work" }, 1374 "text", 1375 "simon.perreault@viagenie.ca" 1376 ], 1377 ["geo", { "type": "work" }, "uri", "geo:46.772673,-71.282945"], 1378 ["key", 1379 { "type": "work" }, 1380 "uri", 1381 "http://www.viagenie.ca/simon.perreault/simon.asc" 1382 ], 1383 ["tz", {}, "utc-offset", "-05:00"], 1384 ["url", { "type": "home" }, "uri", "http://nomis80.org"] 1385 ] 1386 ] 1388 Appendix C. Change History (to be removed prior to publication as an 1389 RFC) 1391 draft-kewisch-vcard-in-json-01 1393 * Added ABNF and improved references in date/time related 1394 sections 1396 * Changes to wording in "vCard Stream" section 1398 * Changes to wording about VALUE parameter when converting to 1399 vCard 1401 * Corrected missing "type" parameter and separator in example 1403 * Minor wording corrections 1405 draft-ietf-jcardcal-jcard-00 1407 * Pubication as a WG draft 1409 draft-ietf-jcardcal-jcard-01 1411 * Changed grouping syntax to use new GROUP parameter and added 1412 respective IANA section 1414 * Added timestamp and date-and-or-time types instead of 1415 converting them from date/time/date-time 1417 * Added a further sentence on preprocessing and escaping to 1418 clarify that JSON escaping must be used 1420 * Described how to handle structured text values and structured 1421 text components with multiple values. 1423 * Corrections and additions to the ABNF Section, adaptions to 1424 example 1426 * Made more clear that complete representation is not mandatory 1428 * Added sheffer-running-code section 1430 * Changed handling of unknown property parameter types 1432 * Minor corrections to sections regarding dates, fixing typos 1434 draft-ietf-jcardcal-jcard-03 1436 * Add LABEL property example and description 1438 * Added acknowledgements 1440 * More typos fixed 1442 draft-ietf-jcardcal-jcard-04 1444 * Added reference to rfc6868 1446 * Various editorial changes per jcardcal issue tracker 1448 * Resolved a few MAY/SHOULD conflicts 1450 * Put the VERSION property into its own section 1452 * Improved GROUP/UNKNOWN registrations by only putting vcard 1453 related information into the registration template 1455 * Removed vcard stream construct. 1457 * Added reference to RFC6868 for both directions 1459 * Corrected some examples and ABNF 1461 draft-ietf-jcardcal-jcard-05 1463 * Updated UNKNOWN registration text to match with jCal text. 1465 draft-ietf-jcardcal-jcard-06 1467 * Various editoral changes based on the IETF reviews. Please see 1468 http://trac.tools.ietf.org/wg/jcardcal/trac/ for details. 1470 Author's Address 1471 Philipp Kewisch 1472 Mozilla Corporation 1473 650 Castro Street, Suite 300 1474 Mountain View, CA 94041 1475 USA 1477 EMail: mozilla@kewis.ch 1478 URI: http://www.mozilla.org/