The ADR property is extended with 11 new granular components (room, apartment, floor, streetnumber, streetname, building, block, subdistrict, district, landmark, direction) because international addresses require components that implementations currently combine into the single street address field, losing structural information.

The N property gains secondary surname and generation components to facilitate formatting with the Unicode CLDR Person Name standard and to properly represent naming conventions (e.g., paternal/maternal surnames) that implementations currently force into the family-name or honorific-suffixes components.

The SOCIALPROFILE property is introduced to replace the widely-used but unregistered X-SOCIALPROFILE experimental property. Similarly, SERVICE-TYPE replaces X-SERVICE-TYPE, providing IANA-registered equivalents for de-facto conventions in vCard address book implementations.

For N property backwards compatibility, secondary surnames currently placed in the family-name component and generational markers in honorific-suffixes should be duplicated in both the new and old components when writing, and readers should prefer the new components when both are populated with equal values.

A PROP-ID value MUST be 1 to 255 octets and MUST contain only ASCII alphanumeric characters (A-Za-z0-9), hyphen (-), or underscore (_). If an application uses PROP-ID, it SHOULD assign a unique identifier to each sibling property of the same name within a vCard component.

For backwards compatibility with N property extensions, implementations SHOULD add secondary surname and generation values to both the newly defined components and their backwards-compatible counterparts (family name / honorific suffixes). When reading, implementations SHOULD ignore the backwards-compatible component value if an equal value is set in the new component.

Multiple occurrences of the GRAMGENDER property MUST be distinguished by the LANGUAGE parameter.

The AUTHOR-NAME parameter value MUST NOT be empty, and implementations MUST take care to quote the name part so it is a valid param-value per RFC 6350 Section 3.3.

The AUTHOR parameter value MUST be quoted because every valid URI (RFC 3986) contains a colon character, which is not allowed unquoted in vCard parameter values.

The LANGUAGE parameter MUST NOT be assigned to the LANGUAGE property itself.

The SCRIPT parameter value MUST be a script subtag as defined in RFC 5646 Section 2.2.3 (four ASCII alpha characters, e.g., 'Latn').

The SERVICE-TYPE parameter value is case-sensitive; its letter case MUST be preserved. The USERNAME parameter value is likewise case-sensitive and MUST be preserved.

When PHONETIC value is 'script' (unknown phonetic system), the SCRIPT parameter MUST also be set. The LANGUAGE parameter SHOULD NOT contain a script subtag; any such subtag MUST be ignored in favor of the SCRIPT parameter.

When reading ADR property values, implementations SHOULD ignore the street component if the ADR property value contains any of the new extended components.

When the DERIVED parameter is present with value 'true', clients MUST NOT update the property. This signals that the property value is derived from other properties in the same vCard (e.g., FN derived from N components).

When the PHONETIC parameter is used, the ALTID parameter MUST be set with equal values on both the related property and the property bearing PHONETIC. If multiple same-named properties share a PHONETIC and equal ALTID, at most one MAY omit the LANGUAGE parameter; all others MUST have LANGUAGE set with distinct values.

When USERNAME is set on an IMPP or SOCIALPROFILE property, the property value type MUST be URI.

When writing ADR properties with the new extended components, implementations SHOULD write a combined value of the new components in the street address component for backwards compatibility.

The CREATED parameter may be set on any property to record the point in time (as a TIMESTAMP per RFC 6350 Section 4.3.5) when that property was created. Updating a property value SHOULD NOT change this creation timestamp.

The CREATED property (cardinality *1) records the timestamp when a vCard was created. Copying the vCard across systems does not reset this value; it typically stays unchanged for the life of the vCard.

The GRAMGENDER property (cardinality *) specifies the grammatical gender a contact prefers for salutations and grammatical constructs. Allowed values are: animate, common, feminine, inanimate, masculine, neuter, plus iana-token or x-name extensions.

The LABEL parameter is formally defined and registered for use with the ADR property to hold a formatted delivery address label. This parameter was described in RFC 6350 Section 6.3.1 but was never entered into the IANA vCard Parameters registry.

registry

The LANGUAGE property (cardinality *1) defines the default language for all human-readable TEXT values in the vCard. The LANGUAGE parameter on an individual property overrides this property-level default.

The PHONETIC parameter indicates that a property contains the phonetic representation of a same-named property. Defined values are: 'ipa' (IPA), 'jyut' (Cantonese Jyutping), 'piny' (Mandarin Hanyu Pinyin), 'script' (unknown system). The parameter is currently defined for use with ADR and N properties.

The PRONOUNS property (cardinality *) holds free-form text pronouns chosen by the contact. It supports the LANGUAGE, PREF, TYPE, and ALTID parameters to express multiple languages or preferences.

The SOCIALPROFILE property (cardinality *) specifies URI or free-text usernames for social media profiles. The SERVICE-TYPE parameter MUST be assigned when the value type is TEXT, and MUST NOT be assigned more than once. Names MUST be compared case-insensitively.

Two new TYPE parameter values are defined for the ADR property: 'billing' (address for receiving invoices) and 'delivery' (address for receiving packages).

IANA vCard Parameters registry is updated to add AUTHOR, AUTHOR-NAME, CREATED, DERIVED, LABEL, PHONETIC, PROP-ID, SCRIPT, SERVICE-TYPE, and USERNAME parameters.

registry

IANA vCard Properties registry is updated to add CREATED, GRAMGENDER, LANGUAGE, PRONOUNS, and SOCIALPROFILE properties, and to add RFC 9554 as an additional reference for the existing ADR and N properties.

registry

IANA vCard Property Values registry is updated to add six GRAMGENDER values (animate, common, feminine, inanimate, masculine, neuter), and the vCard Parameter Values registry is updated to add billing and delivery ADR TYPE values and ipa, jyut, piny, script PHONETIC values.

registry

This specification introduces no new security considerations beyond those already identified in RFC 6350 Section 9, which apply in full to these extensions.

security

The ADR-value structured type is extended from 7 to 18 semicolon-delimited list-component fields, adding room, apartment, floor, streetnumber, streetname, building, block, subdistrict, district, landmark, and direction components after the original seven.

The N-value ABNF is updated to N-value = list-component 6(';' list-component), adding secondary surname and generation as the 6th and 7th semicolon-delimited components.