RFC 7095

jCard: The JSON Format for vCard

📅 published January 2014, from ietf

RFC 7095: jCard: The JSON Format for vCard 🎀

okay bestie, RFC 7095 is all about jCard, a JSON format for contact cards 📇 It was written by P. Kewisch at Mozilla as a Standards Track document in January 2014 (ISSN 2070-1721) and published by the IETF 💖 The title block doesn't list any Obsoletes or Updates entries.

Abstract

okay so this spec defines "jCard," a JSON format for vCard data 💅 vCard is a text format for capturing and swapping info about people and other entities, like phone numbers, email addresses, structured names, and delivery addresses 📮 JSON is a lightweight, text-based, language-independent data interchange format that shows up all over internet apps 🌸

Status of This Memo

this is an Internet Standards Track document ✨

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 if you want more on Internet Standards, check out Section 2 of RFC 5741 🦋

for the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc7095 💜

Copyright Notice

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 🧾 please actually read those, because they spell out your rights and restrictions for this document 🙈 any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
3.  Converting from vCard to jCard  . . . . . . . . . . . . . . .   4
  3.1.  Pre-processing  . . . . . . . . . . . . . . . . . . . . .   4
  3.2.  jCard Object and Syntactic Entities (RFC 6350, Sections
        6.1.1 and 6.1.2)  . . . . . . . . . . . . . . . . . . . .   5
  3.3.  Properties (RFC 6350, Section 6)  . . . . . . . . . . . .   5
    3.3.1.  Special Cases for Properties  . . . . . . . . . . . .   7
      3.3.1.1.  The VERSION Property  . . . . . . . . . . . . . .   7
      3.3.1.2.  Grouping of Properties  . . . . . . . . . . . . .   7
      3.3.1.3.  Structured Property Values  . . . . . . . . . . .   8
  3.4.  Parameters (RFC 6350, Section 5)  . . . . . . . . . . . .  10
    3.4.1.  VALUE Parameter . . . . . . . . . . . . . . . . . . .  10
    3.4.2.  Multi-Valued Parameters . . . . . . . . . . . . . . .  11
  3.5.  Values (RFC 6350, Section 4)  . . . . . . . . . . . . . .  11
    3.5.1.  Text (RFC 6350, Section 4.1)  . . . . . . . . . . . .  12
    3.5.2.  URI (RFC 6350, Section 4.2) . . . . . . . . . . . . .  12
    3.5.3.  Date (RFC 6350, Section 4.3.1)  . . . . . . . . . . .  12
    3.5.4.  Time (RFC 6350, Section 4.3.2)  . . . . . . . . . . .  13
    3.5.5.  Date-Time (RFC 6350, Section 4.3.3) . . . . . . . . .  14
    3.5.6.  Date and/or Time (RFC 6350, Section 4.3.4)  . . . . .  16
    3.5.7.  Timestamp (RFC 6350, Section 4.3.5) . . . . . . . . .  16
    3.5.8.  Boolean (RFC 6350, Section 4.4) . . . . . . . . . . .  17
    3.5.9.  Integer (RFC 6350, Section 4.5) . . . . . . . . . . .  17
    3.5.10. Float (RFC 6350, Section 4.6) . . . . . . . . . . . .  17
    3.5.11. UTC Offset (RFC 6350, Section 4.7)  . . . . . . . . .  18
    3.5.12. Language Tag (RFC 6350, Section 4.8)  . . . . . . . .  18
  3.6.  Extensions (RFC 6350, Section 6.10) . . . . . . . . . . .  18
4.  Converting from jCard into vCard  . . . . . . . . . . . . . .  19
5.  Handling Unrecognized Properties or Parameters  . . . . . . .  19
  5.1.  Converting vCard into jCard . . . . . . . . . . . . . . .  19
  5.2.  Converting jCard into vCard . . . . . . . . . . . . . . .  20
  5.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  20
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
  7.1.  GROUP vCard Parameter . . . . . . . . . . . . . . . . . .  23
  7.2.  UNKNOWN vCard Value Data Type . . . . . . . . . . . . . .  24
8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  24
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  25
Appendix A.  ABNF Syntax  . . . . . . . . . . . . . . . . . . . .  26
Appendix B.  Examples . . . . . . . . . . . . . . . . . . . . . .  27
  B.1.  Example: vCard of the Author of RFC 6350  . . . . . . . .  27
    B.1.1.  vCard Data  . . . . . . . . . . . . . . . . . . . . .  27
    B.1.2.  jCard Data  . . . . . . . . . . . . . . . . . . . . .  28

1. Introduction 📖

the vCard data format [RFC6350] is how you capture and exchange the stuff that normally lives in an address book or directory app 📇 vCard has gone through multiple revisions, and the most recent one is vCard 4 ✨

vCard and the iCalendar data format [RFC5545] have some similarities, so there's also an effort to define a JSON-based calendar format called jCal [JCAL] that's basically the sibling of this spec 👯 the term "JSON" refers to the JavaScript Object Notation defined in [RFC4627] 💜

so the goal here is to define "jCard," a JSON format for vCard data 🎀 the big win of JSON over classic vCard is that it's way easier to process in JavaScript-based widgets and libraries, especially for web apps 🌈

the key design considerations are basically the same as the ones for [JCAL] and [RFC6321], which are:

Round-tripping (turning a vCard into jCard and back again) should give you the same semantic result you started with. For example, all components, properties, and property parameters are guaranteed to be preserved 🔁
The ordering of elements, and the case of property and parameter names, won't necessarily be preserved 🙃
The vCard data semantics are meant to be preserved, so a simple consumer can easily browse the data in jCard 👀 but you still need a full understanding of vCard to modify or fully get what the directory data means 🤓
Extensions to the underlying vCard spec must not lead to needing an update to jCard 🛡️

2. Conventions Used in This Document 🧠

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥

jCard is built on JSON, so the terms "object" and "array," plus the four primitive types (strings, numbers, booleans, and null), are to be interpreted as described in Section 1 of [RFC4627] 💅

some examples in this doc are "partial" JSON documents for illustration. In those, three periods "..." mean a chunk of the document was cut out to keep things compact ✂️

3. Converting from vCard to jCard 🦋

this section describes how vCard objects get converted to jCard using a simple mapping between the vCard data model and JSON elements ✨

in [RFC6350], a vCard object is made up of "properties," "parameters," and "values." The top level of a vCard object holds "properties." A "property" has a "value" and zero or more "parameters" 🧩 each of these has a representation in jCard, which the following sections define. Throughout this document, the JSON version of a vCard object is called a "jCard object" 🌸

3.1. Pre-processing 🧹

vCard uses line folding to cap lines of data at a maximum length (typically 75 octets). This keeps data intact when it travels through stuff like email, see Section 3.2 of [RFC6350] 📬

vCard data also uses an "escape" character sequence for text values and property parameter values. See Section 3.4 of [RFC6350] and also [RFC6868] 🔐

when you convert vCard to jCard, the vCard lines MUST be unfolded first. After that, any vCard escaping MUST be unescaped. Last, JSON escaping (for example, for control characters) MUST be applied 🪄

going the other way, from jCard to vCard, it's reversed. First, the JSON escaping MUST be unescaped. Then vCard escaping MUST be applied. Finally, long lines SHOULD be folded as described in [RFC6350] 🔄

one key difference in how vCard and jCard format values is that jCard uses date/time values aligned with the extended format of [ISO.8601.2004], which is more common in internet apps that use JSON 🗓️ the sections describing the various date and time formats cover the complete representation, reduced accuracy, and truncated representation in more detail 💖

3.2. jCard Object and Syntactic Entities (RFC 6350, Sections 6.1.1 and 6.1.2) 🎀

in Sections 6.1.1 and 6.1.2 of [RFC6350], the BEGIN and END properties delimit a syntactic vCard entity. In jCard, each syntactic entity is an array with two elements, and it's called a "jCard object" 🫧 the first element is the string "vcard," and the second is an array of jCard properties (as described in Section 3.3) that belong to that entity 💜

even though [RFC6350] defines BEGIN and END as properties, they MUST NOT appear as properties in the jCard. The jCard object alone is enough to define a vCard entity 🙅‍♀️ when you convert jCard to vCard, the BEGIN and END properties MUST be added to wrap the properties of the jCard object 🎁

example:

["vcard", [
  /* Add properties in place of this comment */
  ]
]

if you're a consumer of this format and want to define content that can hold multiple jCard objects in the same JSON document, you can use a plain JSON array where each element is a single jCard object 🌈

3.3. Properties (RFC 6350, Section 6) ✨

Okay bestie, every single vCard property gets its own little array in jCard 🎀 It starts with three fixed elements, and then it can have one or more extra elements after that. How many extras depends on whether the property is multi-valued, which is explained in Section 3.3 of [RFC6350] 💅

Here are the fixed elements, in order:

The name of the property, as a lowercase string. vCard says property names are case insensitive and recommends rendering them in uppercase, but in jCard they MUST be in lowercase 💜
An object holding the parameters, see Section 3.4. If the property has no parameters, an empty object {} is used to show that 🫶
The type identifier string of the value, in lowercase. Parsers need to check this so they know the data type and don't rely on assumptions 👀 For structured values, the data type will be "array" 🧚

After those, the rest of the array holds the value or values of the property. For single-value properties the array has exactly four elements. For multi-valued properties, each value is its own element, and there can be any number of extra elements 🌈

In this example, "categories" is multi-valued with two values, and everything else is single-valued:

["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "John Doe"],
    ["gender", {}, "text", "M"],
    ["categories", {}, "text", "computers", "cameras"],
    ...
  ]
]

As Section 3.3.1.3 explains, a property value can be a structured property value. In that case it's shown as an array wrapped inside the array that represents the whole property 🍓

Technically this means the property value isn't shown in the format the type identifier names. It's shown as an array instead. The values inside that wrapped array do match the format the type identifier names, though 🤓

The same goes for multi-valued properties, where some values might be structured property values and get wrapped in an array like this 💖

There's also a special case where one value in a wrapped array has multiple components of its own. Then that value gets its own nested array, with elements that match the value type. Section 3.3.1.3 goes deeper on this 🦋

The big takeaway: parsers have to check the format of each property value. It might match the value type directly, or it might be a structured value where the nested sub-elements match the value type. Don't assume, check! 🙈

3.3.1. Special Cases for Properties

This section covers some properties that get special handling when you convert to jCard 👑

3.3.1.1. The VERSION Property

The vCard format specification [RFC6350] makes the VERSION property mandatory 🎀 The jCard "version" property MUST be represented in the matching jCard component, with the same value as in the vCard. vCards that follow RFC 6350 will contain the value "4.0" 🌸

Also following [RFC6350], the "version" property MUST be the first element of the array that holds a jCard's properties 🥇

3.3.1.2. Grouping of Properties

In vCard [RFC6350], related properties can be grouped together with a grouping construct. The grouping happens by adding a prefix to the property name, made of the group name followed by a dot 🧩

In jCard, that same grouping is done with a "group" parameter that holds the group name. That means a property name in jCard MUST NOT be prefixed by a group name. Bye bye, dot prefix 👋

The "GROUP" parameter MUST NOT be used in vCard. As per [RFC6350], it's only registered to reserve the parameter and avoid collisions 🔒 Formal registration of the "GROUP" parameter is described in Section 7.1 ✨

3.3.1.2.1. Group Conversion Rules

In jCard, the parameter's value is a single opaque string. Here's how the conversion works 🫧

From vCard to jCard, the group construct (see [RFC6350], Section 3.3) gets removed. The "group" parameter takes its place. Its value is a string with the group name, which is case insensitive in both vCard and jCard. The name's case SHOULD be converted into lowercase 💜
When converting from jCard to vCard, the value of the "group" parameter followed by a dot gets prefixed to the property name, and the "group" parameter is thrown out. The "GROUP" parameter MUST NOT appear in the resulting vCard. Following the recommendations in [RFC6350], the name's case SHOULD be converted into uppercase 🍓

Example:

CONTACT.FN:Mr. John Q. Public\, Esq.

is equivalent to:

[ "fn", { "group": "CONTACT" }, "text", "Mr. John Q. Public, Esq." ]

3.3.1.3. Structured Property Values

The vCard spec defines properties with structured values, like "GENDER" or "ADR" 🏠 In vCard, a structured text value is made of one or more text components, split up by the SEMICOLON character. Its jCard equivalent is a structured property value: an array with one element per text component. Empty or missing text components are shown as zero-length strings 🫶

vCard Example:

ADR:;;123 Main Street;Any Town;CA;91921-1234;U.S.A.

jCard Example:

["adr", {}, "text",
  [
  "", "", "123 Main Street",
  "Any Town", "CA", "91921-1234", "U.S.A."
  ]
]

Some vCard properties, like ADR, also allow a structured value element that has multiple values of its own. In that case, the array element for the structured value is itself an array, with one element for each of the component's multiple values 🌈

vCard Example:

ADR:;;My Street,Left Side,Second Shack;Hometown;PA;18252;U.S.A.

jCard Example:

["adr", {}, "text",
  [
  "", "",
  ["My Street", "Left Side", "Second Shack"],
  "Hometown", "PA", "18252", "U.S.A."
  ]
]

In both cases, the array element values MUST have the primitive type that matches the jCard type identifier. In [RFC6350], there are only structured text values, so only JSON strings get used. Extensions might define structured number or boolean values, though, and in those cases JSON number or boolean types MUST be used 🔥

Even though a structured property value is allowed to hold just one component, it is RECOMMENDED to represent it as a single text value instead, leaving out the array completely. A simple implementation MAY choose to keep the array, with the single text value as its element 💅

Similarly, structured values with two text components where one is optional (like "GENDER") can be shown as a single text value. So parsers of jCard data SHOULD check even known property values for structured information, by looking at the JSON data type of the value, which can be an array or a primitive value. This is especially important in languages where you access array members with the same syntax you use to access characters of a string 🙈

Examples:

["gender", {}, "text", ["F", "grrrl"] ],
["gender", {}, "text", "M" ]

Per Section 6.3.1 of [RFC6350], the component separator MUST be specified even if the component value is missing. Similarly, the jCard array holding the structured data MUST contain all required elements, even if they're empty 🧱

vCard Example:

ADR;LABEL="123 Maple Ave\nSuite 901\nVancouver BC\nA1B 2C9\nCan
 ada":;;;;;;

jCard Example:

["adr",
 {"label":"123 Maple Ave\nSuite 901\nVancouver BC\nA1B 2C9\nCanada"},
 "text",
 ["", "", "", "", "", "", ""]
]

3.4. Parameters (RFC 6350, Section 5) 🦋

Property parameters are represented as a JSON object, where each key-value pair stands for a vCard parameter name and its value. The parameter name MUST be in lowercase, and the original case of the parameter value MUST be preserved 💜 For example, the "LANGUAGE" property parameter shows up in jCard under the "language" key. Any new vCard parameters added in the future get converted the same way 🌸

Example:

["role", { "language": "tr" }, "text", "roca"],

3.4.1. VALUE Parameter

vCard defines a "VALUE" property parameter (Section 5.2 of [RFC6350]). This property parameter MUST NOT be added to the parameters object. Instead, the value type gets signaled through the type identifier in the third element of the array that describes the property. When converting a property from vCard to jCard, the value type gets figured out like this ✨

If the property has a "VALUE" parameter, that parameter's value is used as the value type.
If the property has no "VALUE" parameter but has a default value type, the default value type is used.
If the property has no "VALUE" parameter and no default value type, "unknown" is used.

Converting from jCard into vCard goes like this 🔄

If the property's value type is "unknown", no "VALUE" parameter is included.
If the property's value type is the default type for that property, no "VALUE" parameter is included.
Otherwise, a "VALUE" parameter is included, and the value type is used as the parameter value.

See Section 5 for info on handling unknown value types 🧚

3.4.2. Multi-Valued Parameters

In [RFC6350], some parameters allow a comma-separated list of values. To make processing easier in jCard, the value for these parameters MUST be represented in an array holding the separated values. The array elements MUST be string values. Single-value parameters SHOULD be represented using a single string value, though a simpler implementation might prefer an array with one string element 🎀 An example of this kind of parameter is the vCard "SORT-AS" parameter, and more of them may be added in extensions 🌈

The vCard spec needs the value wrapped in DQUOTE characters if a parameter value contains a colon, a semicolon, or a comma. Those extra DQUOTE characters aren't part of the actual parameter value, so they don't get included when the parameter is converted to jCard 💅

Example:

["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["n",
     { "sort-as": ["Harten", "Rene"] },
     "text",
     ["van der Harten", "Rene", "J.", "Sir", "R.D.O.N."]
    ],
    ["fn", {}, "text", "Rene van der Harten"]
    ...
  ]
]

3.5. Values (RFC 6350, Section 4) 💖

The following subsections explain how the vCard property value data types (defined in Section 4 of [RFC6350]) get represented in jCard 🫶

3.5.1. Text (RFC 6350, Section 4.1)

Description: vCard "TEXT" property values are represented by a property with the type identifier "text". The value elements are JSON strings. For details on structured text values, see Section 3.3.1.3.

Example:

["kind", {}, "text", "group"]

3.5.2. URI (RFC 6350, Section 4.2)

Description: vCard "URI" property values are represented by a property with the type identifier "uri". The value elements are JSON strings.

Example:

["source", {}, "uri", "ldap://ldap.example.com/cn=babs%20jensen"]

3.5.3. Date (RFC 6350, Section 4.3.1) 📅

Description: Okay so vCard "DATE" values get a property with the type identifier "date" 💖 The value elements are JSON strings holding the same date that [RFC6350] talks about, just written in the extended format from [ISO.8601.2004], Section 4.1.2 🎀 If you don't use the complete representation, the same date restrictions for reduced accuracy, truncated representation, and expanded representation from [RFC6350], Section 4.3.1 still apply 🫶 Whenever the extended format is not applicable, the basic format MUST be used 💅

ABNF syntax: 🧾

date-complete = year "-" month "-" day ;YYYY-MM-DD

date-noreduc = date-complete
           / "--" month "-" day ; --MM-DD
           / "---" day          ; ---DDD

date = date-noreduc
   / year; YYYY
   / year "-" month ; YYYY-MM
   / "--" month     ; --MM

Examples: 🍓

["bday", {}, "date", "1985-04-12"],
["bday", {}, "date", "1985-04"],
["bday", {}, "date", "1985"],
["bday", {}, "date", "--04-12"],
["bday", {}, "date", "---12"]

This table is the conversion cheat sheet between the vCard DATE format and jCard date 📋 It's only an example though, not a formal specification of the syntax, so the real rules live in [ISO.8601.2000] and [ISO.8601.2004] 🤓

                   +-----------+----------+------------+
                   |           | vCard    | jCard      |
                   +-----------+----------+------------+
                   | Complete  | 19850412 | 1985-04-12 |
                   |           |          |            |
                   | Reduced   | 1985-04  | 1985-04    |
                   |           |          |            |
                   | Reduced   | 1985     | 1985       |
                   |           |          |            |
                   | Truncated | --0412   | --04-12    |
                   |           |          |            |
                   | Truncated | --04     | --04       |
                   |           |          |            |
                   | Truncated | ---12    | ---12      |
                   +-----------+----------+------------+

3.5.4. Time (RFC 6350, Section 4.3.2) ⏰

Description: vCard "TIME" values get a property with the type identifier "time" ✨ The value elements are JSON strings with the same time value from [RFC6350], written in the extended format from [ISO.8601.2004], Section 4.2 🌸 If you skip the complete representation, the same time restrictions for reduced accuracy, decimal fraction, and truncated representation from [RFC6350], Section 4.3.2 still apply 💜 Whenever the extended format is not applicable, the basic format MUST be used 🙈 The seconds value of 60 MUST only be used to account for positive "leap" seconds, and the midnight hour is always represented by 00, never 24 😭 Fractions of a second are not supported by this format. In jCard, UTC offsets are permitted within a time value. Note that this differs from jCal [JCAL], where they are not permitted 🦋

ABNF syntax: 🧾

time-notrunc =  hour [":" minute [":" second]] [zone]

time = time-notrunc
   / "-" minute ":" second [zone]; -mm:ss
   / "-" minute [zone]; -mm
   / "--" second [zone]; --ss

Examples: 🍓

["x-time-local", {}, "time", "12:30:00"],
["x-time-utc", {}, "time", "12:30:00Z"],
["x-time-offset", {}, "time", "12:30:00-08:00"],
["x-time-reduced", {}, "time", "23"],
["x-time-truncated", {}, "time", "-30"]

Here's the TIME conversion table 📋 Same deal as before: it's just an example, and the actual syntax is in [ISO.8601.2000] and [ISO.8601.2004] 🤓

                     +-----------+--------+----------+
                     |           | vCard  | jCard    |
                     +-----------+--------+----------+
                     | Complete  | 232050 | 23:20:50 |
                     |           |        |          |
                     | Reduced   | 2320   | 23:20    |
                     |           |        |          |
                     | Reduced   | 23     | 23       |
                     |           |        |          |
                     | Truncated | -2050  | -20:50   |
                     |           |        |          |
                     | Truncated | -20    | -20      |
                     |           |        |          |
                     | Truncated | --50   | --50     |
                     +-----------+--------+----------+

Also, all combinations may have any zone designator appended, just like in the complete representation 🌈

3.5.5. Date-Time (RFC 6350, Section 4.3.3) 💕

Description: vCard "DATE-TIME" values get a property with the type identifier "date-time" 🎀 The value elements are JSON strings with the same date value from [RFC6350], but written in the extended format from [ISO.8601.2004], Section 4.3 🫶 If you don't use the complete representation, the same date and time restrictions from Sections 3.5.3 and 3.5.4 apply 🧚 Just like [RFC6350] describes, truncating the date part is allowed ✨

Example: 🍓

["anniversary", {}, "date-time", "2013-02-14T12:30:00"],
["anniversary", {}, "date-time", "2013-01-10T19:00:00Z"],
["anniversary", {}, "date-time", "2013-08-15T09:45:00+01:00"],
["anniversary", {}, "date-time", "---15T09:45:00+01:00"]

Here's the DATE-TIME conversion table 📋 It's an example only, not a formal spec, so the real syntax is in [ISO.8601.2000] and [ISO.8601.2004] 🤓

+----------------+----------------------+---------------------------+
| Representation | vCard                | jCard                     |
+----------------+----------------------+---------------------------+
| Complete       | 19850412T232050      | 1985-04-12T23:20:50       |
|                |                      |                           |
| Complete       | 19850412T232050Z     | 1985-04-12T23:20:50Z      |
|                |                      |                           |
| Complete       | 19850412T232050+0400 | 1985-04-12T23:20:50+04:00 |
|                |                      |                           |
| Complete       | 19850412T232050+04   | 1985-04-12T23:20:50+04    |
|                |                      |                           |
| Reduced        | 19850412T2320        | 1985-04-12T23:20          |
|                |                      |                           |
| Reduced        | 19850412T23          | 1985-04-12T23             |
|                |                      |                           |
| Truncated and  | --0412T2320          | --04-12T23:20             |
| Reduced        |                      |                           |
|                |                      |                           |
| Truncated and  | --04T2320            | --04T23:20                |
| Reduced        |                      |                           |
|                |                      |                           |
| Truncated and  | ---12T2320           | ---12T23:20               |
| Reduced        |                      |                           |
|                |                      |                           |
| Truncated and  | --0412T2320          | --04-12T23:20             |
| Reduced        |                      |                           |
|                |                      |                           |
| Truncated and  | --04T23              | --04T23                   |
| Reduced        |                      |                           |
+----------------+----------------------+---------------------------+

As specified in [ISO.8601.2000], the lower-order components may not be omitted in the date part (reduced accuracy), and the higher-order components may not be omitted in the time part (truncation) 🧐 Also, all combinations may have any zone designator appended, just like in the complete representation 🌸

3.5.6. Date and/or Time (RFC 6350, Section 4.3.4) 🗓️

Description: vCard "DATE-AND-OR-TIME" values get a property with the type identifier "date-and-or-time" 💖 The value elements are either a date-time (Section 3.5.5), a date (Section 3.5.3), or a time (Section 3.5.4) value 🎀 Just like Section 4.3.4 of [RFC6350] says, a stand-alone time value MUST always be preceded by a "T" 🫶

Example: 🍓

["bday", {}, "date-and-or-time", "2013-02-14T12:30:00"],
["bday", {}, "date-and-or-time", "---22T14:00"]
["bday", {}, "date-and-or-time", "1985"],
["bday", {}, "date-and-or-time", "T12:30"]

3.5.7. Timestamp (RFC 6350, Section 4.3.5) 🕰️

Description: vCard "TIMESTAMP" values get a property with the type identifier "timestamp" ✨ The value elements are JSON strings with the same timestamp value from [RFC6350], written in the extended format and complete representation from [ISO.8601.2004], Section 4.3.2 💅

Example: 🍓

["rev", {}, "timestamp", "2013-02-14T12:30:00"],
["rev", {}, "timestamp", "2013-02-14T12:30:00Z"],
["rev", {}, "timestamp", "2013-02-14T12:30:00-05"],
["rev", {}, "timestamp", "2013-02-14T12:30:00-05:00"]

Here's the TIMESTAMP conversion table 📋 It's just an example and not a formal specification of the syntax, so check [ISO.8601.2000] and [ISO.8601.2004] for the real thing 🤓

+----------------+----------------------+---------------------------+
| Representation | vCard                | jCard                     |
+----------------+----------------------+---------------------------+
| Complete       | 19850412T232050      | 1985-04-12T23:20:50       |
|                |                      |                           |
| Complete       | 19850412T232050Z     | 1985-04-12T23:20:50Z      |
|                |                      |                           |
| Complete       | 19850412T232050+0400 | 1985-04-12T23:20:50+04:00 |
|                |                      |                           |
| Complete       | 19850412T232050+04   | 1985-04-12T23:20:50+04    |
+----------------+----------------------+---------------------------+

3.5.8. Boolean (RFC 6350, Section 4.4) ✅

Description: vCard "BOOLEAN" values get a property with the type identifier "boolean" 💜 The value element is a JSON boolean value 🌈

Example: 🍓

["x-non-smoking", {}, "boolean", true]

3.5.9. Integer (RFC 6350, Section 4.5) 🔢

Description: vCard "INTEGER" values get a property with the type identifier "integer" 🧚 The value elements are JSON primitive number values 💖

Examples: 🍓

["x-karma-points", {}, "integer", 42]

JSON allows decimals (e.g., 3.14) and exponents (e.g., 2e10) in numeric values 🤔 jCard doesn't prohibit this for "integer" property values. BUT since vCard doesn't support decimals or exponents in integers, any decimals and exponents MUST be eliminated when converting an "integer" value type property from jCard to vCard 😭🔥

3.5.10. Float (RFC 6350, Section 4.6) 🌸

Description: okay so vCard "FLOAT" property values get represented by a property with the type identifier "float", and the value elements are JSON primitive number values 🔢✨

Example:

["x-grade", {}, "float", 1.3]

JSON allows exponents (e.g., 2e10) to be used in numeric values. jCard doesn't prohibit this for "float" property values 🙈 BUT since vCard doesn't support exponents in floats, any exponents MUST be eliminated when converting a "float" value type property from jCard to vCard. no cap, that's a must-do 💅

3.5.11. UTC Offset (RFC 6350, Section 4.7) 🦋

Description: vCard "UTC-OFFSET" property values are represented by a property with the type identifier "utc-offset". The value elements are JSON strings with the same UTC offset value specified by [RFC6350], except the hour and minute components are separated by a ":" character. This is so it lines up with the [ISO.8601.2004] timezone offset, extended format 🕐 consistency is everything, bestie.

Example:

// Note: [RFC6350] mentions use of utc-offset
// for the TZ property as NOT RECOMMENDED
["tz", {}, "utc-offset", "-05:00"]

3.5.12. Language Tag (RFC 6350, Section 4.8) 🌍

Description: "LANGUAGE-TAG" property values are represented by a property with the type identifier "language-tag". The value elements are JSON strings containing a single language-tag, as defined in [RFC5646] 🗣️

Example:

["lang", {}, "language-tag", "de"]

3.6. Extensions (RFC 6350, Section 6.10) 🧚

vCard extension properties and property parameters (the ones with an "X-" prefix in their name) get handled the same way as everything else 💜 The property is an array, the property parameter is an object, and the name is the same as the vCard extension but in lowercase. So the "X-FOO" property in vCard turns into the "x-foo" jCard property. Main character energy. See Section 5 for how to deal with default values for unrecognized extension properties or property parameters.

4. Converting from jCard into vCard 💌

When converting property and property parameter values, the names SHOULD be converted to uppercase. Vibes-wise, vCard names are case insensitive, but common practice is to keep them all uppercase, following the actual definitions in [RFC6350] 🔠

Character escaping and line folding MUST be applied to the resulting vCard data as required by [RFC6350] and [RFC6868]. Non-negotiable, babe ✨

When converting to vCard, the "VALUE" parameter MUST be added to properties whose default value type is unknown but do not have a jCard type identifier "unknown". The "VALUE" parameter MAY be omitted for properties using the default value type. The "VALUE" parameter MUST be omitted for properties that have the jCard type identifier "unknown". It's giving organized 🗂️

5. Handling Unrecognized Properties or Parameters 🔍

In vCard, properties can have one or more value types as specified by their definition, and one of those values is defined as the default. When a property uses its default value type, the "VALUE" property parameter doesn't need to be specified on the property. For example, "BDAY"'s default value type is "date-and-or-time", so "VALUE=date-and-or-time" doesn't need to be set as a property parameter. However, "BDAY" also allows a "text" value to be specified, and if that's used, "VALUE=text" has to be set as a property parameter 🎂

When new properties are defined or "X-" properties get used, a vCard-to-jCard converter might not recognize them and might not know what the appropriate default value types are. It still needs to be able to preserve the values, though 🥺 A similar issue comes up for unrecognized property parameters.

In jCard, a new "unknown" property value type is introduced. Its purpose is to let unknown property values survive round-tripping between jCard and vCard. To avoid collisions, this specification reserves the "UNKNOWN" property value type in vCard. It MUST NOT be used in any vCard as specified by [RFC6350], nor any extensions to it. The type is therefore registered to the "vCard Value Data Types" registry; see Section 7.2 📋

5.1. Converting vCard into jCard 🔄

Any property that doesn't include a "VALUE" property parameter, and whose default value type is not known, MUST be converted to a primitive JSON string. The content of that string is the unprocessed value text. Also, the value type MUST be set to "unknown".

To correctly implement this format, it's critical to use the value type "unknown" when the default value type is not known. If this requirement is ignored and, for example, "text" is used, additional escaping may occur that breaks round-tripping values. Don't be that person 😭

Any unrecognized property parameter MUST be converted to a string value, with its content set to the property parameter value text, treated as if it were a "TEXT" value. 🎀

5.2. Converting jCard into vCard 🔁

In jCard, the value type is always explicitly specified. It gets converted to vCard using the vCard "VALUE" parameter, except in the following two cases:

If the value type specified in jCard matches the default value type in vCard, the "VALUE" parameter MAY be omitted.
If the value type specified in jCard is set to "unknown", the "VALUE" parameter MUST NOT be specified. The value MUST be taken over in vCard without processing.

5.3. Examples 🧁

The following is an example of an unrecognized vCard property (one that uses a "URI" value as its default), and the equivalent jCard representation of that property.

vCard:

X-COMPLAINT-URI:mailto:abuse@example.org

jCard:

["x-complaint-uri", {}, "unknown", "mailto:abuse@example.org"]

The following is an example of how to cope with jCard data where the parser was unable to identify the value type. Note how the "unknown" value type is not added to the vCard data, and escaping, aside from standard JSON string escaping, is not processed. 🙌

jCard:

["x-coffee-data", {}, "unknown", "Stenophylla;Guinea\\,Africa"]

vCard:

X-COFFEE-DATA:Stenophylla;Guinea\,Africa

There are no standard properties in [RFC6350] that have a default type of integer. Consequently, this example uses the following extended property that we treat as having a default type (namely, integer) known to the parser, in order to illustrate how a property with a known default type would be transformed. 🍀

jCard:

["x-karma-points", {}, "integer", 95]

vCard:

X-KARMA-POINTS:95

The following is an example of an unrecognized vCard property parameter (one that uses a "FLOAT" value as its default) specified on a recognized vCard property, and the equivalent jCard representation of that property and property parameter. 🌈

vCard:

GENDER;X-PROBABILITY=0.8:M

jCard:

["gender", { "x-probability": "0.8" }, "text", "M"]

6. Security Considerations 🔐

This specification defines how vCard data can be "translated" between two different data formats -- the original text format and JSON -- with a one-to-one mapping. That way all the semantic data in one format (properties, parameters, and values) is preserved in the other. It does not change the semantic meaning of the underlying data itself, and it doesn't impose or remove any security considerations that apply to the underlying data.

The use of JSON as a format does have its own inherent security risks, as discussed in Section 7 of [RFC4627]. Even though JSON is considered a safe subset of JavaScript, it should be kept in mind that a flaw in the parser for JSON data could still impose a threat that doesn't arise with conventional vCard data. 💀

With this in mind, when using jCard, the parser for JSON data should be aware of the security implications. For example, the use of JavaScript's eval() function is only allowed using the regular expression in Section 6 of [RFC4627]. A native parser with full awareness of the JSON format should be preferred.

Bestie, be extra careful with eval(). It's a whole vibe check 🚨

In addition, it is expected that this new format will result in vCard data being more widely disseminated (e.g., with use in web applications rather than just dedicated "contact managers"). Main feed energy 📱

In all cases, application developers have to conform to the semantics of the vCard data as defined by [RFC6350] and associated extensions, and all of the security considerations described in Section 9 of [RFC6350], or any associated extensions, are applicable. 🫶

7. IANA Considerations 📋

This document defines a MIME media type for use with vCard in JSON data. This media type SHOULD be used for the transfer of calendaring data in JSON.

Type name: application
Subtype name: vcard+json
Required parameters: none
Optional parameters: version, as defined for the text/vcard media type in [RFC6350], Section 10.1.
Encoding considerations: Same as encoding considerations of application/json as specified in [RFC4627], Section 6.
Security considerations: See Section 6.
Interoperability considerations: This media type provides an alternative format for vCard data based on JSON.
Published specification: This specification.
Applications which use this media type: Applications that currently make use of the text/vcard media type can use this as an alternative. Similarly, applications that use the application/json media type to transfer directory data can use this to further specify the content.
Fragment identifier considerations: N/A
Additional information:
- Deprecated alias names for this type: N/A
- Magic number(s): N/A
- File extension(s): N/A
- Macintosh file type code(s): N/A
Person & email address to contact for further information: vcarddav@ietf.org
Intended usage: COMMON
Restrictions on usage: There are no restrictions on where this media type can be used.
Author: See the "Author's Address" section of this document.
Change controller: IETF

7.1. GROUP vCard Parameter 🎀

IANA has added the "GROUP" parameter to the "vCard Parameters" registry, which was initialized in Section 10.3.2 of [RFC6350]. Usage of the "GROUP" parameter is further described in Section 3.3.1.2 of this document. Reservation energy, fr fr ✨

Namespace: <empty>
Parameter name: GROUP
Purpose: To simplify the jCard format.
Description: The "GROUP" parameter is reserved for the exclusive use of the jCard format described in this document. It MUST NOT be used in plain vCard [RFC6350], nor in xCard [RFC6351].
Format definition: When converting from jCard to vCard, the value of the "GROUP" parameter is used as part of the property name. Therefore, the value is restricted to characters allowed in property names, namely ALPHA, DIGIT, and "-" characters. When used, the "GROUP" parameter MUST NOT be empty.
Example: As this registration serves as a reservation of the "GROUP" parameter so that it is not used in vCard, there is no applicable vCard example. Examples of its usage in jCard can be found in this document. 🧚‍♀️

7.2. UNKNOWN vCard Value Data Type 🦋

okay so IANA added the "UNKNOWN" value data type to the "vCard Value Data Types" registry, which got set up back in Section 10.3.3 of [RFC6350] 💅 and Section 5 of this document explains how "UNKNOWN" gets used 🧚

Value name: UNKNOWN
Purpose: To allow preserving property values whose default value type is not known during round-tripping between jCard and vCard. 🔄
Format definition: (Not applicable)
Description: The "UNKNOWN" value data type is reserved for the exclusive use of the jCard format. It MUST NOT be used in plain vCard [RFC6350]. 🙅‍♀️
Example: As this registration serves as a reservation of the "UNKNOWN" type so that it is not used in vCard, there is no applicable vCard example. 🙈 Examples of its usage in jCard can be found in this document. 💖

8. Acknowledgments 🫶

the author wants to give a huge shoutout to Cyrus Daboo, Mike Douglass, William Gill, Erwin Rehme, Dave Thewlis, Simon Perreault, Michael Angstadt, Peter Saint-Andre, Bert Greevenbosch, and Javier Godoy for their valuable contributions 🌸 this whole spec started out as work from the XML-JSON technical committee of the Calendaring and Scheduling Consortium ✨

9. References 📚

9.1. Normative References

these are the must-read sources the spec leans on 👀

[ISO.8601.2000]
           International Organization for Standardization, "Data
           elements and interchange formats -- Information
           interchange -- Representation of dates and times", ISO
           8601, December 2000.

[ISO.8601.2004]
           International Organization for Standardization, "Data
           elements and interchange formats -- Information
           interchange -- Representation of dates and times", ISO
           8601, December 2004.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4627]  Crockford, D., "The application/json Media Type for
           JavaScript Object Notation (JSON)", RFC 4627, July 2006.

[RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
           Languages", BCP 47, RFC 5646, September 2009.

[RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
           August 2011.

[RFC6868]  Daboo, C., "Parameter Value Encoding in iCalendar and
           vCard", RFC 6868, February 2013.

9.2. Informative References

these are the extra reading that's good to know about, but not required 🤓

[JCAL]     Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON
           format for iCalendar", Work in Progress, December 2013.

[RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling
           Core Object Specification (iCalendar)", RFC 5545,
           September 2009.

[RFC6321]  Daboo, C., Douglass, M., and S. Lees, "xCal: The XML
           Format for iCalendar", RFC 6321, August 2011.

[RFC6351]  Perreault, S., "xCard: vCard XML Representation", RFC
           6351, August 2011.

[calconnect-artifacts]
           The Calendaring and Scheduling Consortium, "Code Artifacts
           and Schemas", <http://www.calconnect.org/artifacts.shtml>.

Appendix A. ABNF Syntax 🧩

okay so this is the ABNF syntax for vCard in JSON, written the [RFC5234] way 💅 ABNF symbols that aren't described here come from [RFC4627] 🙌 this part is non-normative, so it's just here for reference, babe 💜

the numeric section numbers in the comments point to sections in [RFC6350] 📖 there are extra semantic restrictions too, especially about which properties and subcomponents are allowed in each component, and you can read all about those in this document and [RFC6350] ✨ more ABNF might also be floating around on the Internet at [calconnect-artifacts] 🌐

; A jCard object uses the name "vcard" and a properties array.
; Restrictions to which properties may be specified are to
; be taken from RFC 6350.
jcardobject = begin-array
              DQUOTE component-name DQUOTE value-separator
              properties-array
              end-array

; A jCard property consists of the name string, parameters object,
; type string, and one or more values as specified in this document.
property = begin-array
           DQUOTE property-name DQUOTE value-separator
           params-object value-separator
           DQUOTE type-name DQUOTE
           property-value *(value-separator property-value)
           end-array
properties-array = begin-array
                   [ property *(value-separator property) ]
                   end-array

; Property values depend on the type-name. Aside from the value types
; mentioned here, extensions may make use of other JSON value types.
property-value = simple-prop-value / structured-prop-value
simple-prop-value = string / number / true / false
structured-prop-value =
    begin-array
    [ structured-element *(value-separator structured-element) ]
    end-array

; Each structured element may have multiple values if
; semantically allowed.
structured-element = simple-prop-value / structured-multi-prop
structured-multi-prop =
    begin-array
    [ simple-prop-value *(value-separator simple-prop-value) ]
    end-array

; The jCard params-object is a JSON object that follows the semantic
; guidelines described in this document.
params-object = begin-object
                [ params-member *(value-separator params-member) ]
                end-object
params-member = DQUOTE param-name DQUOTE name-separator param-value
param-value = string / param-multi
param-multi = begin-array
              [ string *(value-separator string) ]
              end-array

; The type MUST be a valid type as described by this document. New
; value types can be added by extensions.
type-name = "text" / "uri" / "date" / "time" / "date-time" /
            "boolean" / "integer" / "float" / "utc-offset" /
            "language-tag" / x-type

; Property, parameter, and type names MUST be lowercase. Additional
; semantic restrictions apply as described by this document and
; RFC 6350.
component-name = lowercase-name
property-name = lowercase-name
param-name = lowercase-name
x-type = lowercase-name
lowercase-name = 1*(%x61-7A / DIGIT / "-")

Appendix B. Examples 🎀

this part has an example of a vCard object next to its jCard version, so you can see the two side by side 👯‍♀️

B.1. Example: vCard of the Author of RFC 6350

B.1.1. vCard Data

BEGIN:VCARD
VERSION:4.0
FN:Simon Perreault
N:Perreault;Simon;;;ing. jr,M.Sc.
BDAY:--0203
ANNIVERSARY:20090808T1430-0500
GENDER:M
LANG;PREF=1:fr
LANG;PREF=2:en
ORG;TYPE=work:Viagenie
ADR;TYPE=work:;Suite D2-630;2875 Laurier;
 Quebec;QC;G1V 2M2;Canada
TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501
EMAIL;TYPE=work:simon.perreault@viagenie.ca
GEO;TYPE=work:geo:46.772673,-71.282945
KEY;TYPE=work;VALUE=uri:
 http://www.viagenie.ca/simon.perreault/simon.asc
TZ:-0500
URL;TYPE=home:http://nomis80.org
END:VCARD

B.1.2. jCard Data

["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Simon Perreault"],
    ["n",
      {},
      "text",
      ["Perreault", "Simon", "", "", ["ing. jr", "M.Sc."]]
    ],
    ["bday", {}, "date-and-or-time", "--02-03"],
    ["anniversary",
      {},
      "date-and-or-time",
      "2009-08-08T14:30:00-05:00"
    ],
    ["gender", {}, "text", "M"],
    ["lang", { "pref": "1" }, "language-tag", "fr"],
    ["lang", { "pref": "2" }, "language-tag", "en"],
    ["org", { "type": "work" }, "text", "Viagenie"],
    ["adr",
       { "type": "work" },
       "text",
       [
        "",
        "Suite D2-630",
        "2875 Laurier",
        "Quebec",
        "QC",
        "G1V 2M2",
        "Canada"
       ]
    ],
    ["tel",
      { "type": ["work", "voice"], "pref": "1" },
      "uri",
      "tel:+1-418-656-9254;ext=102"
    ],
    ["tel",
      { "type": ["work", "cell", "voice", "video", "text"] },
      "uri",
      "tel:+1-418-262-6501"
    ],
    ["email",
      { "type": "work" },
      "text",
      "simon.perreault@viagenie.ca"
    ],
    ["geo", { "type": "work" }, "uri", "geo:46.772673,-71.282945"],
    ["key",
      { "type": "work" },
      "uri",
      "http://www.viagenie.ca/simon.perreault/simon.asc"
    ],
    ["tz", {}, "utc-offset", "-05:00"],
    ["url", { "type": "home" }, "uri", "http://nomis80.org"]
  ]
]

Author's Address 💌

Philipp Kewisch
Mozilla Corporation
650 Castro Street, Suite 300
Mountain View, CA  94041
USA

EMail: mozilla@kewis.ch
URI:   http://www.mozilla.org/

📦 where this page comes from

ietf: rfc7095 2014-01
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms

RFC 7095

RFC 7095: jCard: The JSON Format for vCard 🎀

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction 📖

2. Conventions Used in This Document 🧠

3. Converting from vCard to jCard 🦋

3.1. Pre-processing 🧹

3.2. jCard Object and Syntactic Entities (RFC 6350, Sections 6.1.1 and 6.1.2) 🎀

3.3. Properties (RFC 6350, Section 6) ✨

3.3.1. Special Cases for Properties

3.3.1.1. The VERSION Property

3.3.1.2. Grouping of Properties

3.3.1.2.1. Group Conversion Rules

3.3.1.3. Structured Property Values

3.4. Parameters (RFC 6350, Section 5) 🦋

3.4.1. VALUE Parameter

3.4.2. Multi-Valued Parameters

3.5. Values (RFC 6350, Section 4) 💖

3.5.1. Text (RFC 6350, Section 4.1)

3.5.2. URI (RFC 6350, Section 4.2)

3.5.3. Date (RFC 6350, Section 4.3.1) 📅

3.5.4. Time (RFC 6350, Section 4.3.2) ⏰

3.5.5. Date-Time (RFC 6350, Section 4.3.3) 💕

3.5.6. Date and/or Time (RFC 6350, Section 4.3.4) 🗓️

3.5.7. Timestamp (RFC 6350, Section 4.3.5) 🕰️

3.5.8. Boolean (RFC 6350, Section 4.4) ✅

3.5.9. Integer (RFC 6350, Section 4.5) 🔢

3.5.10. Float (RFC 6350, Section 4.6) 🌸

3.5.11. UTC Offset (RFC 6350, Section 4.7) 🦋

3.5.12. Language Tag (RFC 6350, Section 4.8) 🌍

3.6. Extensions (RFC 6350, Section 6.10) 🧚

4. Converting from jCard into vCard 💌

5. Handling Unrecognized Properties or Parameters 🔍

5.1. Converting vCard into jCard 🔄

5.2. Converting jCard into vCard 🔁

5.3. Examples 🧁

6. Security Considerations 🔐

7. IANA Considerations 📋

7.1. GROUP vCard Parameter 🎀

7.2. UNKNOWN vCard Value Data Type 🦋

8. Acknowledgments 🫶

9. References 📚

9.1. Normative References

9.2. Informative References

Appendix A. ABNF Syntax 🧩

Appendix B. Examples 🎀

B.1. Example: vCard of the Author of RFC 6350

B.1.1. vCard Data

B.1.2. jCard Data

Author's Address 💌