The latest major revision to vCard is vCard 4.0, a milestone improvement over vCard 3.0.
Described in RFC 6350, vCard Format Specification, it is designed as a generalization of the vCard 2.1 and 3.0 formats that it is a general contact information format instead of just representing a business card or a directory profile. RFC 6350 was developed through the CalConnect VCARD technical committee and published in August 2011 through IETF.
A brief history of vCard 4.0
In the early days of CalConnect (i.e. 2006/2007), our members had a fair amount of discussion whether we should tackle a revision of vCard (which was then at 3.0, but 2.1 was still in general use) due to the various shortcomings of the standard.
Eventually, CalConnect hosted an open vCard workshop during the CalConnect meeting at MIT in September 2007 with the goal of meeting fellow users and vendors of vCard to discuss existing issues. A fair number of interested parties, including CalConnect members and external individuals, came and decided that it is time to update the existing standard.
The conclusion of the CalConnect vCard workshop led the IETF to undertake a revision of vCard and assigned an editor. The resulting standard is vCard 4.0, which resolves some immediate concerns raised during the workshop while keeping it compatible with 3.0.
Benefits of vCard 4.0
vCard 4.0 provides a number of important updates over its predecessor:
- additional standardized properties to support modern businesses and use cases
- independent MIME type designated for vCard usage as a standalone file
- a standardized method of extending the vCard standard without modifying its core
- introduces standardized measures aimed to resolve incompatible vendor-specific properties used by client implementations
- greatly simplifies the vCard data format and resolves previous inconsistencies
vCard 4.0 also allows for better representation of information about individuals, groups of people, companies, and locations, and implementing it in your software gives you greater flexibility to store and exchange this information.
Changes in vCard 4.0 from vCard 3.0
vCard 4.0 represents an incremental but large improvement over the previous vCard 3.0 and 2.1 formats.
The following sections contain discussion of the differences between vCard 4.0 and previous versions of vCard, as well as information on how to migrate existing software from the vCard 3.0 format to the newer vCard 4.0 format.
Unfortunately, Appendix A of RFC 6350 contains an incomplete list of the changes from vCard 3.0 to vCard 4.0. In this document we will provide more detailed information on why you should utilize vCard 4.0, and supplement that information with a brief discussion of the implications and benefits of each change.
Instead of having two complementary specifications in vCard 3.0 in form of RFC 2425 and RFC 2426, they are merged into just one document, RFC
- This change makes it much easier for implementers to understand the vCard format definition, and much implementation simpler.
New vCard elements can be registered with IANA, allowing for central
control and extension of the vCard format without modification of the
core standard. This registry would simplify development of extensions
and resolve previous incompatiblities with widely used, non-standard,
vendor-specific properties (
X-properties) that plagued versions 2.1
and 3.0 by large vendors.
vCard 4.0 requires the encoding to be in the
set, eliminating any incompatibilities between programs encoding or
reading the format in different character sets, which is extremely
important for the global usage of the vCard format.
In international settings, it is increasingly common for business cards
to be in multiple languages. vCard 4.0 introduces a new parameter type
LANGUAGE to allow multiple translations of a property, effectively
allowing a business card to be encoded in multiple languages at once.
UTF-8 is now the only supported character set, eliminating any incompatibilities which can arise from different pieces of software implementing vCard with different character sets and languages.
The new property type
LANG is also introduced to allow specifying the
preferred language of the vCard’s subject.
Unique MIME type
Version 4.0 formally introduces the
text/vcard MIME type, allowing
vCard to be a standalone file format. This is one of the most important
changes in vCard 4.0.
Users can now directly store, edit and open them using their preferred applications instead of requiring vCards to be attachments. With vCards being standalone files they are more distributable, and it is more easy than ever to allow reading and exchange of contact data.
Previously, vCard existed only as a MIME type attached to email or as
information extracted from a directory profile through the
text/directory MIME type, which was unsuitable and confusing at best.
The new type remains a valid MIME type for message attachments.
Representing groups and locations
vCard 4.0 introduces the
location property values for the
KIND property, allowing a vCard to represent a group or geographical
KIND:group, an additional
MEMBER property is introduced allowing
group members to be represented inside the group’s vCard, which makes it
possible for the vCard to be self-contained about information pertaining
to the group.
With the advent of the cloud era, simultaneous collaborative editing of
information has become commonplace. vCard 4.0 has been designed exactly
with that in mind. The
PID property (and the
allows the user to edit properties on one device and complete the edit
on another, tracking and merging actions performed on each, allowing a
seamless experience with contact information updates.
New Properties and Parameter Values
The following properties have been added for vCard 4.0:
LANG (described above),
properties give vCard a much greater flexibility in representing
information about people and groups.
KINDspecifies the kind of object a particular vCard represents: an individual, group of people, organization, or geographic.
GENDERspecifies the sex and gender identity of the person or object a particular vCard represents. This property is optional but can be useful in helping people identify themselves.
ANNIVERSARYspecifies the date of marriage (or equivalent) of the person that a particular vCard represents.
CLIENTPIDMAPgives a global meaning to a local PID source identifier.
RFC 2739 (Calendar attributes for vCard and LDAP)
RFC 4770 (vCard Extensions for Instant Messaging (IM))
IMPP) have been incorporated into the vCard 4.0
specification and further standardized. This merge simplifies the
specification of vCard and makes implementation easier.
TYPE parameter values have been made available to
more properties. These tags help specify whether a property is related
to an individual’s workplace or home. When neither of these tags are
present and the
KIND property is set to
individual, the implication is
that a property relates to both the individual’s home and workplace. If
KIND is set to any other value and these tags are present, there is no
implication to the property.
pref value of the
TYPE parameter indicating preference when
multiple values are specified now includes a positive integer value
indicating the level of preference. This can be useful for ranking
multiple values, for example when providing several phone number
contacts, they can be ranked in order of most preferred to least
PID parameters have been added to further improve the
ability to identify properties.
MEDIATYPE parameter has been added to specify the type of media to
expect when a value is a URI. This parameter replaces the
parameter when used for indicating the specific media type of a
CHARSET parameters have been removed. The
parameter is no longer required as the vCard format now only supports
one character set.
CLASS properties have been removed as they
are no longer useful with the modern usage of vCard.
TYPE parameter values
ADR property have been removed to simplify the address definition.
Inline vCards, such as the value of the
AGENT property from vCard 3.0
are no longer supported. This improves the readability of the vCard
Migrating from vCard 3.0 to vCard 4.0
When making changes to your software that implements vCard, you should carefully review the new vCard specification, and make sure that you support all new properties, as well as the expanded parameters for old properties.
Additionally, implementing vCard 4.0 is simplified by the standalone file format (be sure to continue to support MIME encoded vCards) and by the reduction in supported character sets.
Ideally, your software should continue supporting vCard 3.0 alongside the implementation of vCard 4.0, until the newest format is widely used. For most use cases, vCard 4.0 represents a vast improvement over the previous version, and should be adopted immediately.