ietf-corpus

rfc-9555

JSContact: Converting from and to vCard

M. Loffredo, R. Stepanek
date2024-05 streamIETF areaart wgcalext statusPROPOSED STANDARD pages60 canonicalhttps://www.rfc-editor.org/rfc/rfc9555 doi10.17487/RFC9555 errataview
This document defines how to convert contact information between the JSContact and vCard data formats. It defines conversion rules for every JSContact and vCard element registered at IANA at the time of publication. It also defines new JSContact properties as well as vCard properties and parameters, to support converting arbitrary or unknown JSContact and vCard elements.

updates

Extracted elements (28)

design-rationale §2.3.1

The ALTID parameter is not mapped to a registered JSContact property but is used by multiple conversion rules to combine logically related vCard property instances (e.g., multilingual N or ADR variants) into a single JSContact object, driving the PHONETIC and LANGUAGE conversion rules.

json

design-rationale §2.5.3

The vCard GENDER property has no direct IANA-registered JSContact counterpart; implementors should use the Card's speakToAs property or the new RFC 9554 GRAMGENDER/PRONOUNS properties instead, and may preserve GENDER verbatim via vCardProps. This reflects the richer grammatical-gender model in JSContact.

json

design-rationale §2.3.13

vCard EXPERTISE LEVEL values ('beginner', 'average', 'expert') are remapped to JSContact PersonalInfo levels ('low', 'medium', 'high') rather than passed verbatim, normalizing terminology across the two formats while preserving relative ordering semantics.

json

interoperability-note §2.6.1

ADR's legacy 'extended address' and 'street address' components map to 'apartment' and 'name' only when the ADR value does not use the new RFC 9554 structured format; if the new format is present, these backwards-compatible components must be ignored on conversion from vCard.

json

interoperability-note §2.2.2

Several vCard temporal types—TIME, DATE-TIME, DATE-AND-OR-TIME, and DATE values specifying only a month or only a day—do not convert to any JSContact datetime type and must instead be preserved via the vCardProps mechanism (Section 2.15).

json

interoperability-note §2.7.6

The vCard TEL property's default TYPE is 'voice', but the JSContact Phone object's features property is absent by default. Implementations SHOULD only set Phone features if the TEL property actually carries a TEL-specific TYPE parameter, to avoid spurious 'voice' features on converted entries.

json

interoperability-note §2.3.11

There is no single standard rule for building the JSContact localizations property from the vCard LANGUAGE parameter; implementations may use either 'one patch per property' or 'bundle patches by parent' strategies, and the choice is implementation-specific.

json

interoperability-note §2.8.2

UTC-OFFSET TZ values convert to an IANA Time Zone Database name only when the offset has zero minutes and the hour is between -12 and +14 inclusive (e.g., '-0500' → 'Etc/GMT+5', zero → 'Etc/UTC'). All other UTC-OFFSET and URI TZ values must be preserved via vCardProps.

json

normative-requirement §3.3.1 MUST

If the JSCOMPS parameter is set and its value is valid, implementations MUST set the isOrdered property of the Name or Address object to 'true'; otherwise, they MUST set it to 'false'.

json

normative-requirement §3.1 MUST

If the JSContact Name object's full property is set, implementations MUST use its value for the vCard FN property. If full is absent, implementations SHOULD derive it from components and MUST set the DERIVED parameter on FN. If full cannot be derived, FN MUST be set to the empty value.

json

normative-requirement §2.8.3 MUST

Implementations MUST convert vCard ADR, GEO, and TZ properties to the same Address object instance when their GROUP parameter values match, or when GROUP is absent but is set on other ADR, GEO, or TZ properties.

json

normative-requirement §2.1.2 MUST

Implementations MUST generate Id-type key values that are valid according to the definition of the Id type in RFC 9553. Multivalued vCard properties map to JSContact JSON objects keyed by Id-typed strings; any valid generation scheme (e.g., incrementing counter) is permitted.

json

normative-requirement §2.6.1 SHOULD

Implementations SHOULD set the new ADR components defined in RFC 9554 (apartment, block, building, direction, district, floor, landmark, room, street number, subdistrict) even if all their values are the empty string.

json

normative-requirement §2.1.1 MUST

Implementations that convert a vCard without a UID property MUST generate a unique identifier as value for the uid property. This value SHOULD be the same when converting the same vCard multiple times, but how to achieve this is implementation-specific.

json

normative-requirement §2.3.9 MUST NOT

The jCard GROUP parameter MUST NOT be set in a vCard; it is exclusively for use in jCard. Implementations that wish to preserve the exact property group name of a vCard property MAY record it in the JSContact vCardProps or vCardParams properties.

json

normative-requirement §3.2.1 MUST

The JSPTR parameter MUST be set on every JSPROP vCard property. The JSON value of JSPROP MUST be compact (no insignificant whitespace). All JSPROP properties in a vCard form a PatchObject; this PatchObject MUST only be applied after all other vCard properties have been converted, and MUST NOT be applied if invalid.

json

normative-requirement §2.2.5 MUST

The LANGUAGE-TAG vCard type value MUST be a language tag as defined in RFC 5646, and the URI vCard type value MUST be a URI as defined in RFC 3986 Section 3.

json

normative-requirement §3.1 MUST

When converting JSContact to vCard, each multivalued JSContact property converts to separate vCard property instances, and each PROP-ID parameter MUST be set to the Id-typed key of the converted value.

json

normative-requirement §2.5.5 MUST

When the JSCOMPS parameter is set on N or ADR, the order in the JSContact components property MUST adhere to the order of the JSCOMPS parameter value, and the isOrdered property MUST be set to 'true'. When JSCOMPS is absent, isOrdered MUST be 'false' and defaultSeparator MUST NOT be set.

json

protocol-element §3.3.1

JSCOMPS is a new vCard parameter on N and ADR that records the ordered sequence and separators for JSContact name or address components. Its structured value consists of a default separator entry followed by positional and separator entries, preserving isOrdered semantics across round-trips.

json

protocol-element §3.2.1

JSPROP is a new vCard TEXT property that represents an arbitrary JSContact property in vCard. Its value is the JSON-encoded value of the JSContact property; it requires the JSPTR parameter and may appear multiple times. Together, all JSPROP properties in a vCard form a PatchObject applied after other conversions.

json

protocol-element §3.3.2

JSPTR is a new vCard parameter used exclusively on JSPROP. Its value is a JSON pointer (RFC 6901) that identifies the JSContact property within the Card object corresponding to the JSPROP value. The pointer MUST NOT reference into an array.

json

protocol-element §2.15.3

vCardName (String, optional) is a new JSContact property on any JSContact object that records the name of the originating vCard element. It allows round-trip preservation of the vCard property name when multiple vCard properties (e.g., IMPP and SOCIALPROFILE) map to the same JSContact type.

json

protocol-element §2.15.2

vCardParams (String[String|String[]], optional) is a new JSContact property on any JSContact object that holds vCard parameters for which no IANA-registered JSContact counterpart exists, encoded as a JSON object of parameter name-to-value mappings per RFC 7095 Section 3.3.

json

protocol-element §2.15.1

vCardProps (JCardProp[], optional) is a new JSContact property on the Card object that holds vCard properties for which no IANA-registered JSContact property exists, encoded as jCard property arrays per RFC 7095 Section 3.3.

json

registry §5.1

IANA has added JSPROP to the 'vCard Properties' registry (RFC 6350 Section 10.3.1), and JSPTR to the 'vCard Parameters' registry (RFC 6350 Section 10.3.2), both referencing RFC 9555.

registry, json

registry §5.3

IANA has added vCardName (String), vCardParams (String[String|String[]]), and vCardProps (JCardProp[]) to the 'JSContact Properties' registry, and the JCardProp type to the 'JSContact Types' registry, all since version 1.0, change controller IETF.

registry, json

security-consideration §4

This specification defines only conversion rules between JSContact and vCard. The security considerations for parsing and formatting these data formats—including injection risks and data validation—are inherited from RFC 9553 Section 4 and RFC 6350 Section 9 and are not restated here.

security, json