vCard MIME Directory Profile
obsoleted by
- rfc-6350 — vCard Format Specification
Extracted elements (30)
The ROLE type is provided separately from TITLE to avoid confusion: ROLE captures business category or occupation (based on X.520 Business Category), while TITLE captures job title or functional position (based on X.520 Title). Conflating them would lead to incorrect usage.
The SORT-STRING type was added because sorting algorithms would incorrectly order vCards with compound, prefixed, or culturally non-obvious names (e.g., Dutch patronymics, Chinese compound surnames) without an explicit sort key distinct from the display name.
Non-standard private type extensions using the "X-" prefix may be defined bilaterally between cooperating agents without IANA registration, following the mechanism defined in RFC 2045.
vCard v3.0 (this specification) differs from vCard v2.1 in multiple incompatible ways: QUOTED-PRINTABLE encoding is eliminated in favor of B encoding only; CRLF in text values uses \n backslash escaping; COMMA and SEMICOLON in text values must be backslash-escaped; the CHARSET type parameter is eliminated; the TYPE= prefix on parameter values is now required.
A vCard object MUST contain the FN, N, and VERSION types. These three properties are mandatory in every conformant vCard.
For PHOTO and LOGO types, the TYPE parameter values MUST be one of the IANA registered image formats or a non-standard image format.
For the ADR type, component values MUST be specified in their corresponding position; when a component value is missing, the associated SEMI-COLON separator MUST still be present.
GEO longitude and latitude values MUST be specified as decimal degrees and should be specified to six decimal places to allow granularity within a meter.
Inline encoded binary data MUST be encoded using the "B" encoding format (RFC 2047), and the ENCODING type parameter MUST be used when specifying inline binary data. Long lines of encoded binary data SHOULD be folded to 75 characters.
Lines longer than 75 characters SHOULD be folded according to the folding procedure described in MIME-DIR. Folding is done after content encoding; unfolding is done before decoding.
Predefined data type values MUST NOT be repeated in COMMA-separated value lists except within the N, NICKNAME, ADR, and CATEGORIES value types. Any SEMI-COLON character in a text value MUST be escaped with a BACKSLASH character.
The content entity MUST begin with BEGIN:VCARD and MUST end with END:VCARD. If the PROFILE type is present, its value MUST be "VCARD".
The UTC-OFFSET value MUST use the extended ISO 8601 format with a colon separator between hours and minutes (e.g., +hh:mm). Hour values are 00-23 and minute values are 00-59, with leading zeroes required.
The VERSION type MUST be present in every vCard object, and its value MUST be "3.0" if the vCard conforms to this specification.
Within an embedded vcard value type (used in AGENT), type declarations MUST be terminated with the backslash escape sequence \n or \N instead of CRLF, and COMMA, SEMI-COLON, and COLON characters MUST be backslash-escaped.
The AGENT type specifies another person who will act on behalf of the vCard subject. Its value can be an inline vcard value, a URI reference, or plain text, and typically represents an administrator or assistant who is separately addressable.
The CLASS type specifies the access classification for a vCard object. Valid values include PUBLIC, PRIVATE, CONFIDENTIAL, iana-tokens, and x-names. This captures the owner's intent for general access to the vCard information.
The KEY type carries a public key or authentication certificate associated with the vCard subject. Inline binary content must use ENCODING=b; the TYPE parameter should specify an IANA registered format such as X509 or PGP.
The PRODID type identifies the product that created the vCard object. Implementations SHOULD use a method such as Formal Public Identifiers (ISO 9070) to ensure uniqueness of the text value.
The REV type specifies when the vCard data was last revised, using a date-time or date value. Together with the URL type, it supports freshness tracking for distributed vCard data.
The SORT-STRING type provides family name or given name text for national-language-specific sorting of the FN and N types, since locale-specific sorting rules (e.g., Dutch "van der", Chinese compound names) may differ from literal field order.
The CLASS type specifies a desired access classification policy for a vCard, but that policy is not enforced in any way by the protocol itself. It represents intent only.
vCard information may become out of date. Where data vitality is important, the URL type SHOULD be specified to allow retrieval of current data, and the REV type can indicate the last update time.
vCard objects have no inherent authentication or privacy. When spoofed vCard information is a concern, vCards SHOULD be transported using a security mechanism that provides authentication or privacy for MIME objects.
A vCard content line is structured as [group '.'] name *( ';' param ) ':' value CRLF, where the name is an iana-token or x-name and folded lines must be unfolded before parsing.
ESCAPED-CHAR sequences in text values are: \\ for backslash, \; for SEMI-COLON, \, for COMMA, and \n or \N for newline.
The ADR type encodes a structured delivery address with seven SEMI-COLON-separated components in order: post office box, extended address, street address, locality, region, postal code, and country name.
The GEO type encodes global position as two SEMI-COLON-separated float values representing latitude then longitude (LAT;LON ordering), expressed as signed decimal degrees.
The N type encodes a structured name with five SEMI-COLON-separated components in order: Family Name, Given Name, Additional Names, Honorific Prefixes, and Honorific Suffixes. Each component may contain multiple COMMA-separated values.
The UTC-OFFSET value type is encoded as ('+' / '-') 2DIGIT ':' 2DIGIT (hours:minutes), representing a signed offset from Coordinated Universal Time.