Sustainability of Digital Formats: Planning for Library of Congress Collections

Virtual Card Format (vCard) is a versatile data format designed for exchanging electronic representations of contact information. vCard is commonly referred to as an "electronic business card" and is fully and openly standardized through IETF RFC 6350. The vCard file contains the same type of content typically found on a physical business card, such as a contact’s name, address, phone number and email but may also list more personal data such as birthday or even organizational data such as line of supervision. Being digital, vCards can contain graphics (including headshots or ID photos), video, and audio as well as textual data. These files are shared across a wide variety of communication channels including email, instant messaging, text messaging, and website embedding. A single vCard file can contain information for one or more contacts. These digital cards are versatile, extending beyond personal descriptions to potentially represent various directory objects, including organizations, departments, or even buildings. However, the predominant use remains the representation of individuals.

vCards can be generated manually, stored as files, or more commonly, created by directory services like X.500 or Lightweight Directory Access Protocol (LDAP) servers.

Structure

According to David Woods in Programming Internet Email, vCard follows a straightforward structure composed of key-value pairs. It commences with a BEGIN keyword indicating the format and concludes with a corresponding END keyword. The version number is included, specifying the format used. Each piece of information in the vCard is represented by its own keyword. Custom tags can be added by applications, prefixed with "x-" as per the specification RFC 6350 Section 6.10. While parsing vCards, whitespaces are disregarded. Semicolons, when used within the text, need to be escaped with a backslash, particularly in properties like N and ADR.

vCard's content entity must initiate with the BEGIN property set to "VCARD," and the value is case-insensitive. While traditionally vCards conclude with "END:VCARD," the specification for Version 2.1 does not mandate this, making it optional. However, for Version 3 and above, "END:VCARD" became a requirement.

vCard supports the embedding of images and sound files using the MIME encoding standard. Sections 6.2.4 and 6.7.5 of the specification outline the requirements for images and sounds, respectively.

Originally known as "The Electronic Business Card". The 'v' in vCard stands for 'Versit' or 'virtual'. The terms Virtual Contact File and Virtual Card Format are used by some sources, but neither is official and is not referenced in the specification.

Refer to Phil Harvey’s “ExifTool vCard Tags” for a comprehensive list of vCard tags.

vCard is fully documented in RFC 6350 and its antecedents, RFC 2425, RFC 2426, and RFC 4770.

See Format Specifications for a list of related specifications.

vCard has been widely adopted since the mid-1990s and has support from many major companies including: Apple, Claris, Four11, IBM, Lotus Development, Lucent Technologies, NetManage, Siemens, Google, and Novell.

Rights to vCard were held by the Versit Consortium until December 1996 when they were transferred to the Internet Mail Consortium (IMC). IMC held the rights until 2004 when they transferred to CalConnect.

Files primarily consist of key-value pairs and can be read using a text editor. Relatively easy to decipher and does not require specific tools to get information from the files with the exception of images which will not appear in a text editor.

To use and replicate as intended to be used, within email systems, would require advanced development work.

Information can be perceived through the key-value pairs:

"A vCard consists of a list of name-value pairs. It begins with a BEGIN keyword, which names the format, and ends with a matching END keyword. The version number of the format used is included … Each piece of information to be presented has its own keyword".

vCard announces itself in the first line with "BEGIN:VCARD" and announces its version on the second line with the VERSION tag.

vCard Origins and Evolution

vCard was initially created by Versit in 1990 as part of a global initiative founded by Apple Computer, AT&T, IBM, and Siemens. Over the years, the ownership and distribution of vCard technology transitioned to the Internet Mail Consortium (IMC) in 1996. At that time, the Versit Consortium, responsible for vCard, was disbanded, and IMC inherited the intellectual property. CalConnect gained rights to vCard in 2006.

vCard 4.0 and CalConnect's Role

In 2007, CalConnect hosted an open workshop, addressing existing issues and paving the way for a revision of vCard. The IETF took on the task, resulting in vCard 4.0, which addressed concerns raised during the workshop while maintaining compatibility with its predecessor. CalConnect, initiated in 2004, has played a crucial role in managing vCard standards since version 3.0. Its contributions are published through IETF RFCs for open adoption.

Versions

The primary standardized versions of vCard are 2.1, 3.0, and 4.0.

Version 2.1

Unlike Version 3.0, Version 2.1 is not an Internet proposed standard, yet it boasts widespread implementation. Version 2.1 is different from 3.0 in four ways:

• 1. The VERSION, N, and END properties are all optional.
• 2. TYPE keyword is not used. Any data is listed after the property value.
• 3. The QUOTED-PRINTABLE encoding option exists. See Wikipedia for more details on this encoding option.
• 4. BASE64 is used instead of the shorthand “b” as an encoding type.

Version 3.0

Version 3.0 differs from Version 2.1 in two ways:

• 1. Version 3.0 contains the ability to extend types by utilizing sub-types. These are then followed by a list of more detailed parameters.
• 2. This version also includes a REV type that specifies when the vCard was updated.

Version 4.0

The Calendar and Scheduling Consortium (CalConnect) led standardization work on Version 4.0. Appendix A of Version 4.0’s specification lists these changes as:

• 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
• standardized measures aimed to resolve incompatible vendor-specific properties used by client implementations
• simplification of the vCard data format and resolution of previous inconsistencies