The ADR property's first two components (post office box and extended address) SHOULD be left empty. Experience with vCard 3 showed these components are plagued with interoperability issues, so emptying them maximizes interoperability.

YYYYMM date format is disallowed to prevent confusion with YYMMDD. Similarly, YYYY-MM-DD is disallowed because vCard uses only ISO 8601 basic format, not extended format.

Property and parameter names are case-insensitive. Based on experience with vCard 3 interoperability, it is RECOMMENDED that property and parameter names be upper-case on output to maximize compatibility with existing implementations.

Unfolding in vCard differs from RFC 5322: vCard removes both the CRLF and the following whitespace character, whereas RFC 5322 only removes the CRLF. Implementations SHOULD unfold lines in a way that properly restores original multi-octet UTF-8 sequences, as simple implementations may incorrectly fold in the middle of such sequences.

A COMMA character in a value MUST be escaped with a BACKSLASH. A SEMICOLON in a field of a compound property MUST be escaped with a BACKSLASH. BACKSLASH characters in values MUST be escaped with a BACKSLASH. NEWLINE characters MUST be encoded as \n or \N.

A vCard implementation MUST ignore properties with a CALSCALE parameter value that it does not understand.

A vCard object MUST include the VERSION and FN properties. VERSION MUST come immediately after BEGIN:VCARD.

An "org" kind vCard MUST NOT contain MEMBER properties. MEMBER properties MUST NOT be present unless the value of the KIND property is "group".

Applications MUST ignore x-param and iana-param values they don't recognize. This applies to all property parameters.

Compound properties allowing multiple instances MUST NOT be encoded in a single content line. In all other cases, escaping MUST NOT be used.

Content lines SHOULD be folded to a maximum width of 75 octets, excluding the line break. Multi-octet characters MUST remain contiguous and must not be split across folded lines.

Implementations MUST support FLOAT precision equal to or better than IEEE binary64 (double). Scientific notation is disallowed.

The charset for vCard is UTF-8 as defined in RFC 3629. There is no way to override this; it is invalid to specify a value other than "UTF-8" in the "charset" MIME parameter.

security

The FN (formatted name) property MUST be present in the vCard object. It has cardinality 1* (one or more instances per vCard must be present).

The TEL property value SHOULD be a URI (preferably using the "tel" URI scheme per RFC 3966) rather than a free-form text value; free-form text is retained only for backward compatibility with vCard 3.

The TZ property utc-offset value type SHOULD NOT be used because UTC offsets vary with daylight saving time shifts and regional re-basing; named timezone identifiers (e.g., from the Olson database) are preferred.

The VERSION property MUST be present and MUST have the value "4.0" for vCards conforming to this specification. It MUST appear immediately after BEGIN:VCARD.

The GENDER property exposes sensitive personal information about biological sex and gender identity. The SOURCE property may reveal the URI of a directory service holding additional personal data. Implementations should apply appropriate access controls and consider whether to include such properties when sharing vCards.

privacy

The ALTID parameter tags property instances as alternative representations of the same logical property (e.g., translations). Two instances are alternatives if and only if their property names and ALTID values are identical. Property instances sharing the same ALTID count as 1 toward cardinality.

The CLIENTPIDMAP property gives a global meaning to a local PID source identifier. Its value is a semicolon-separated pair: a small positive integer (matching the second field of a PID parameter) and a URI. Zero is not allowed as a source identifier. The PID parameter MUST NOT be applied to the CLIENTPIDMAP property itself.

The GENDER property specifies sex (biological) and gender identity as a two-component structured value separated by a semicolon. The sex component is a single letter (M/F/O/N/U or empty); the gender identity component is free-form text. Both components are optional.

privacy

The KEY property carries a public key or authentication certificate associated with the vCard entity. Its value is a URI by default, or may be reset to text. Supported parameters include MEDIATYPE, ALTID, PID, PREF, and TYPE.

security, crypto, pkix

The KIND property specifies what the vCard represents. Defined values are "individual" (default), "group", "org", and "location". Implementations MUST support these values. If absent, "individual" MUST be assumed. If present with an unknown value, the implementation SHOULD act neutrally.

The PID parameter identifies a specific property instance among multiple instances, analogous to UID on a per-property basis. Its value is a single positive integer or a pair of positive integers separated by a dot. Each distinct PID source identifier in a vCard MUST have an associated CLIENTPIDMAP property.

The PREF parameter (optional) indicates the preferred instance of a property. Its value MUST be an integer between 1 and 100, where lower values indicate higher preference. When absent, the instance is treated as least preferred. The value is relative only to other instances of the same property in the same vCard.

This document establishes four IANA vCard Elements registries: (1) Properties Registry, (2) Parameters Registry, (3) Value Data Types Registry, and (4) Values Registries (one per property requiring an enumerated values registry). New entries require Expert Review or Standards Action depending on type. A vendor namespace ("vnd-" prefix) is available for private-use registrations.

registry

This document registers the "text/vcard" media type with IANA. The charset parameter MUST be "UTF-8" when present. The media type carries vCard data per the format defined in this specification.

registry

vCard data can contain sensitive personal information including names, addresses, phone numbers, email addresses, photographs, and cryptographic keys. Implementations must consider access control and privacy when storing, transmitting, or publishing vCard data. The SOURCE property can expose the location of directory services, and the KEY property can carry authentication credentials.

security, privacy

A vCard object is encoded as BEGIN:VCARD CRLF, VERSION:4.0 CRLF, one or more content lines, END:VCARD CRLF. Each content line follows the pattern [group "."] name *(";"; param) ":" value CRLF. Folded lines are indicated by a CRLF immediately followed by a single whitespace character (SP or HTAB).

Date and time value types (DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, TIMESTAMP) are based on ISO 8601:2004 basic format only. Reduced accuracy and truncated representations are permitted; expanded representation and decimal fractions for TIME are forbidden. A stand-alone TIME in DATE-AND-OR-TIME is always preceded by "T" for unambiguous parsing.

The ADR (delivery address) property is a structured value of seven semicolon-separated components in sequence: post office box, extended address, street address, locality, region, postal code, and country name. When a component is missing, its separator MUST still be present.

The N (structured name) property encodes Family Names, Given Names, Additional Names, Honorific Prefixes, and Honorific Suffixes as five semicolon-separated list-components. Individual components may contain multiple values separated by COMMA. ABNF: N-value = list-component 4(";" list-component).