Unlike Version 3.0, the older Version 2.1 is not an Internet proposed standard nor will it ever be. It is, however, widely implemented. Many vendors of email-related products either use vCard 2.1 as the underlying structure of their address books or allow for the importation into their proprietary format. This section will introduce vCard 2.1 and briefly show its differences from Version 3.0. The goal here is to provide enough information for the reader to successfully parse either of the two formats. In fact, since Version 3.0 is rather new as of this writing and largely unimplemented, anyone writing programs or scripts to parse vCards are encouraged to handle both versions for the near future.

By and large, types defined for Version 3.0 vCards are also available under Version 2.1, although there are some minor syntactical changes.

Anyone familiar with the last section will readily recognize the following example as a vCard. We will address each of the differences found in this example, which is the vCard for the Internet Mail Consortium.

BEGIN:VCARD
N:Internet Mail Consortium
FN:Internet Mail Consortium
ORG:Internet Mail Consortium;
EMAIL;INTERNET;WORK:[email protected]
TEL;WORK;VOICE:+1 831 426 9827
TEL;WORK;FAX:+1 831 426 7301
ADR;POSTAL:;;127 Segre Place;Santa Cruz;CA;95060;USA
LABEL;POSTAL;DOM;ENCODING=QUOTED-PRINTABLE:127 Segre place=0D=0A=
 Santa Cruz, CA 95060=0D=0AUSA
URL:http://www.imc.org/
TZ:-08:00 LOGO;GIF;ENCODING=BASE64:
 R01GODlhogBNAPEAAP////+AgP8AAAAAACH5BAEAAAAALAAAAACiAEOAAAL/BISpy+1i
 opy02ouz3rzTB4aMR5bmiXriCqbuC8cVSy/yjeddz

Some differences stand out immediately: there is no END line, nor is a VERSION number given. In Version 2.1 both are optional, whereas they are mandatory in the later version. With Version 2.1, one is not guaranteed to have an N line, either.

The next thing to notice is the handling of subtypes; whereas in Version 3.0, an Internet email address was given like this:

EMAIL;TYPE=INTERNET,WORK:[email protected]

Version 2.1 did not yet have the TYPE keyword; each subtype was simply listed before the colon. It is not hard to see why the change was made. Those types (e.g., PHOTO) that have more than one subtype (ENCODING, TYPE, VALUE) required further delineation. This is the key to understanding the difference between the two formats: Version 3.0 was made more extensible by the IETF process.

A similar situation may be seen in the LOGO line. The line:

LOGO;GIF;ENCODING=BASE64:
 R01GODlhogBNAPEAAP////+AgP8AAAAAACH5BAEAAAAALAAAAACiAEOAAAL/BISpy+1i
 opy02ouz3rzTB4aMR5bmiXriCqbuC8cVSy/yjeddz

is meant to convey an embedded GIF image that is base64 encoded. There is no TYPE= preceding the GIF designator, and the ENCODING subtype marker is BASE64 instead of b (although the two represent the same encoding algorithm).

The ENCODING of the postal address label given in the LABEL line is QUOTEDPRINTABLE (described in Chapter 3): this encoding type is no longer used in Version 3.0. Note that in Version 3.0, we used to denote a linebreak (regardless of the local operating system involved), but in Version 2.1, the quoted-printable encoding method is used, and CRLF combinations are used to break embedded lines. In quoted-printable, a CRLF combination appears as =OD=OA.

So, to summarize, Version 2.1 vCards differ from the proposed standard in these ways:

There are also some differences between how the two version of vCards are attached to email messages. We’ll look at that next.