Line folding, a requirement of plain-text vCard, is a non-issue in XML. Conversion from vCard to xCard is performed after unfolding; conversion from xCard to vCard is performed before folding.

The VERSION property present in plain-text vCard is intentionally absent in xCard. Its versioning role is played by the XML namespace URI (urn:ietf:params:xml:ns:vcard-4.0), which includes the version number; future vCard revisions will use a different namespace.

vCard parameters, properties, and value types are each mapped to XML elements. Parameters are wrapped in a <parameters> child element inside property elements; structured property values (e.g., N) are expressed as XML element trees rather than positional fields.

xCard defines a 1-to-1 mapping between plain-text vCard and XML, enabling lossless round-tripping. The XML representation is preferred in contexts where an XML engine is already available, avoiding a standalone vCard parser.

json

It is RECOMMENDED to limit extensions to the property level (rather than embedding unrecognized XML within a standard property's content) to ensure all data is preserved intact during round-trip conversions between xCard and plain-text vCard.

Properties in XML namespaces other than the vCard 4 namespace are wrapped as-is inside an XML property when converting xCard to vCard. Conversely, the content of XML properties in plain-text vCard is copied as-is to XML.

A vCard XML parser MUST ignore XML elements and attributes for which it does not recognize the expanded name, and MUST also follow the normal behavior of ignoring XML processing instructions whose target is not recognized.

Cardinalities of the original vCard format (RFC 6350) MUST still be respected, as the RELAX NG schema cannot enforce cardinality constraints.

Certain ordering constraints imposed by the XML schema on value enumerations (e.g., type parameters) MUST be respected for the xCard to be valid, although reordering MAY occur during conversion to or from plain-text vCard.

New XML vCard property and parameter element names MUST be lower-case to ensure correct round-tripping between XML and plain-text vCard.

The <vcards> root element MUST be present even when only a single vCard is represented in an XML document.

Usage of XML namespaces for extensibility is RECOMMENDED for extensions that have no equivalent in plain-text vCard. Unregistered extensions starting with 'X-' and 'VND-...-' are expressed using elements starting with 'x-' and 'vnd-...-'.

When converting from vCard to xCard, any property lacking a VALUE parameter whose default value type is unknown MUST be converted using the <unknown> XML element containing the unprocessed value text. Any unrecognized property parameter MUST also be converted using <unknown>.

When converting from xCard to vCard, any <unknown> property value XML element MUST be converted directly into a vCard value, and the containing property MUST NOT have a VALUE parameter.

The root element is <vcards>, which contains one or more <vcard> elements each representing a complete vCard. The <group> element represents vCard groups, with a 'name' attribute holding the group name, and may contain property elements.

The <unknown> element is used as a value type XML element to carry the raw text of unrecognized property values or parameter values during vCard-to-xCard conversion, preserving data without semantic interpretation.

An XML namespace is registered with IANA: URI urn:ietf:params:xml:ns:vcard-4.0, registrant contact IESG. This namespace serves as the version identifier for xCard and replaces the plain-text VERSION property.

registry

The MIME media type application/vcard+xml is registered. It has no required parameters; the charset parameter (value 'utf-8' STRONGLY RECOMMENDED per RFC 3023) is optional. Encoding considerations and security considerations follow application/xml (RFC 3023).

registry

All security considerations applicable to plain-text vCard (RFC 6350) apply equally to xCard. Additionally, XML Signature and XML Encryption can be applied to xCard documents to provide authentication and confidentiality respectively.

security, crypto

The <adr> property element contains sub-elements <pobox>, <ext>, <street>, <locality>, <region>, <code>, and <country>, plus an optional <parameters> child; it also supports a <label> parameter not present in RFC 6350's core parameter set.

The <n> property element contains structured sub-elements <surname>, <given>, <additional>, <prefix>, and <suffix> as XML children; these named elements replace the positional semicolon-delimited fields of plain-text vCard.

The <parameters> element is a container child of property elements holding parameter sub-elements such as <language>, <pref> (integer 1–100), <altid>, <pid>, <type>, <mediatype>, <calscale>, <sort-as>, <geo>, and <tz>.

The xCard schema (Appendix A, RELAX NG) defines value type elements including <text>, <uri> (xsd:anyURI), <date>, <time>, <date-time>, <timestamp>, <boolean>, <integer>, <float>, <utc-offset>, and <language-tag>, each with pattern-constrained string content corresponding to RFC 6350 value types.