Summary

  • draft-ietf-calext-vcard4-bis-00 supplies strong rules for matching vCard instances and property instances through UID, PID and CLIENTPIDMAP, while deliberately leaving other matches to the synchronization engine.
  • A compact synchronized card is a state artifact, not a full history. Transport protection, collection sync, record matching, heuristic merge, conflict policy and later correctness each require their own receipt.

The number matched before the explanation did

Consider two address books that started from one shared contact. Both users add a second telephone number while offline. Each device assigns the new property a different global PID because each edit arose in a different source context. When the cards meet again, the format's mandatory rules do not say those two properties are the same.

The example in revision 00 then introduces a particularly smart synchronization engine. It notices that the telephone values are identical and treats them as one property even though their global PID values differ. The standard permits that decision. The resulting property carries both PID values, and both devices converge on the same card.

This is a plausible result. It may be exactly what the users wanted. It is also the moment at which syntax gives way to local judgment.

The final vCard can show that one telephone property now represents both editing contexts. It cannot, by itself, show which comparison function made the decision, whether number normalization removed an extension, whether one device had stale information, whether the users intended two usage contexts, whether a policy approved the merge or whether an operator later overrode it. The converged state is evidence of what the engine stored. It is not a receipt for why the engine was entitled to store it.

That boundary matters far beyond contact software. Synchronization systems routinely convert distributed histories into one convenient present. The present is what applications need for lookup and action. The history is what operators need when the present is disputed. A format can help the first without automatically supplying the second.

Revision 00 is a working specification, not a deployment result

Revision 00 of vCard Format Specification is dated 2 July 2026 and expires on 3 January 2027. It is a CALENDAR EXTENSIONS Working Group Internet-Draft intended for the Standards Track. If approved, it would obsolete RFC 6350. It is not yet an RFC, a statement that a particular address book implements the draft or evidence that two products make the same discretionary merge.

The draft describes a mature and important format. A vCard can carry names, addresses, telephone numbers, email addresses, organizations, photographs, keys, calendars and relationships. Its grammar and property registry let independent software exchange a representation without inventing a private contact syntax.

That common representation is real infrastructure. The restraint is to say exactly what it coordinates. It tells software how a field is encoded, how repeated properties are identified and which matches are mandatory or prohibited. It does not authenticate the person represented by the card. It does not prove a telephone number still reaches that person. It does not appoint the sender as the authority for every field. It does not choose every conflict policy.

The distinction follows the Running-Code Primacy discipline in docs/heng-lu-note.md: publication, implementation, validation, deployment, use and observed outcome are separate events. A contact format becomes operational only through parsers, stores, transport protocols, synchronization engines, user decisions and downstream actions. No document status can stand in for those receipts.

UID creates a record edge, not a human identity verdict

The synchronization section begins with the card instance. It defines synchronization as the intelligent merging of two representations of the same object. UID is the principal deterministic edge: when two vCard instances have equivalent UID values, they MUST be matched.

Equivalence is more precise than a plain string comparison. If both values are valid URIs, RFC 3986 equivalence applies. Otherwise the values are compared character for character after vCard escaping is removed for text values. A MEMBER reference uses the same equivalence rules when it points at another card.

This is useful because a shared contact must remain recognizable after two copies evolve separately. A stable UID prevents a synchronization engine from treating every received copy as a new person. It gives implementations a common answer to a narrow question: which record instances belong in one reconciliation process?

The narrowness is crucial. Revision 00 gives UID cardinality *1, so a card may have at most one UID but need not always have one. If UIDs are absent or non-equivalent, the engine MAY still match cards at its discretion. Even where equivalent UIDs force a record match, the format has not proved that the identifier was issued correctly, that the two senders referred to the same real-world person, or that a malicious copy did not reuse the identifier.

A UID is therefore authoritative inside the matching algorithm. It is not a biometric check, a legal identity, a current relationship or consent to combine every field. Conflating those layers turns a valuable deterministic key into an authority claim the format was never designed to make.

PID separates a value from the number used to name it

Record matching is only the first step. A card can contain several EMAIL or TEL properties, and the engine must decide which property in one copy corresponds to which property in the other.

The PID parameter gives a property a local value number and, when needed, a source number. The first field can be read as the property's local identifier. The second field is deliberately small and local: it has meaning only within that particular vCard instance.

CLIENTPIDMAP gives the source number a global context by mapping it to a URI. Every distinct source number present in PID values must have a corresponding map entry, and zero is forbidden. Two PID values can represent the same global property value when the local value is the same and their source numbers resolve through CLIENTPIDMAP to equivalent URIs.

This design avoids pretending that a small integer is globally unique. Device A can use source 1 and Device B can also use source 1; the map tells a synchronization engine whose namespace each number occupies. It is a compact indirection layer between local representation and distributed identity.

The map is still metadata, not a signature. Nothing about CLIENTPIDMAP:2;urn:uuid:… proves the device possessing that UUID authored the field, that the mapping was not copied or altered, or that the source is authorized to overwrite another source. The mapping supports comparison. Authentication, authorization and provenance require their own mechanisms.

That difference is easy to miss because the field is called a client PID map and its value looks globally distinctive. Distinctiveness is not custody. A URI can be a useful name without becoming a verified actor.

The MUST rules create safety rails

Revision 00 does not simply tell engines to guess. It establishes several strong constraints.

Properties belonging to unmatched cards MUST NOT be matched. Differently named properties MUST NOT be matched. On already matched cards, same-named properties with maximum cardinality one MUST be matched. Same-named properties whose PID parameters resolve to the same global value MUST also be matched.

These rules prevent a class of arbitrary reconciliation. A telephone property cannot silently become an email property. A field from an unrelated card cannot be pulled into the current contact merely because its text resembles another value. A stable PID edge cannot be ignored whenever a vendor finds a different heuristic convenient.

The mandatory edges are the format's strongest contribution to synchronization. They reduce divergence between implementations by identifying cases where local discretion would do more harm than good.

They also expose the remaining authority surface. For same-named properties that do not meet the mandatory identity conditions, the engine MAY match them at its discretion. This is not a defect hidden between the lines. It is an explicit handoff. The standard recognizes that real data contains spelling differences, normalized telephone forms, equivalent addresses and user intent that a compact syntax cannot decide universally.

Minimum Initial Specification supports exactly this architecture when it is applied with discipline. Standardize the smallest reliable common edges. Leave contextual future decisions local. But local freedom is not freedom from accountability. The engine that exercises the MAY owns the decision and should be able to explain it.

Two emails survive; two telephones collapse

The simultaneous-edit example makes the handoff unusually visible.

Two devices share a card with the same UID. Each later adds an email property and a telephone property. Device one assigns its additions a PID rooted in its own source context. Device two creates another source identifier and CLIENTPIDMAP entry.

When the records synchronize, the new email properties have different global PID values. The engine leaves them unmatched, so both addresses are copied into the result. The two telephone properties also have different global PID values. Yet their visible values are the same, and the example's smart engine chooses to match and merge them.

The outcome is sensible if both entries mean one number. It is wrong if the identical digits represented different extensions, service contexts, confidence levels or source obligations that were not encoded in the compared form. The draft cannot settle that because the relevant context belongs to applications and users.

The operator therefore needs a decision receipt at the precise point of discretion. It should record the two input property hashes, their original PIDs and source maps, the normalization procedure, the rule or model version, confidence, policy threshold, chosen action, retained aliases, actor and timestamp. If a human confirms the merge, that confirmation should be recorded separately from the engine's suggestion.

Without this record, a future reviewer sees only the one telephone property with two PIDs. That proves the synchronized state remembers both property identities. It does not reconstruct the reason they were collapsed.

CLIENTPIDMAP inconsistency marks another local boundary

CLIENTPIDMAP entries are not ordinary contact properties. Revision 00 says the synchronization engine handles them separately and must keep them consistent across matched cards. The draft's example then states that if they are inconsistent, the result is up to the engine and undefined by the document.

This is a precise boundary, not permission to improvise silently. Inconsistency could mean a simple renumbering, a stale copy, a collision, a damaged card or a hostile attempt to change a source association. A universal conflict rule may be unsafe because the surrounding storage and trust models differ.

The minimum safe response is to preserve the conflicting inputs, stop automatic destructive resolution, expose the reason code and require the local policy to choose. A consumer may quarantine the card. Another may retain both contexts. A tightly controlled service may consult a signed history. What it should not do is convert an undefined standard-level case into an unlogged overwrite and later cite vCard conformance as the authority.

The distinction protects the standard as much as the operator. The standard promises interoperable structure. The implementation owns the behavior outside the defined structure. Blurring the two makes deployment failures look like specification failures and makes local policy appear externally mandated.

Global context can be simplified faster than history can be reconstructed

After the example synchronizes, it performs a final compression. Because only two devices participated, the cards can discard one CLIENTPIDMAP context, renumber the properties and represent the same useful result with a shorter record.

Revision 00 explicitly says the details of this global-context simplification are unspecified. The example illustrates a possibility that the author considers worth investigating. It is not a complete algorithm or a claim that every deployment can erase context safely.

The compact card remains useful for future contact operations. It still contains the names, addresses and telephone number the applications need. Within the example's assumptions, the renumbered PIDs can preserve the matching relationships that matter going forward.

What changes is the evidentiary surface. Before simplification, the second source URI showed that some values arose in another client context. After simplification, several values are expressed as if they occupy one remaining source namespace. The record has become a projection optimized for current synchronization, not a durable account of the route by which the current state emerged.

This is common in distributed systems. Compaction, garbage collection and snapshotting make systems operable. An event log grows without bound; a current-state projection answers the current query. The mistake is to discard the history and then call the projection a history.

An accountable implementation may simplify the live vCard while preserving a separate append-only merge receipt: original object hashes, source maps, mapping transformation, conflict decisions and resulting object hash. That separates the efficient serving representation from the audit representation. Neither needs to impersonate the other.

Secure transport protects a message, not a merge judgment

The draft's security considerations are direct: vCards contain sensitive information, have no inherent authentication or confidentiality, and may be carried inside mechanisms such as S/MIME. Mail transport can also be monitored, replayed or forged. Directory services should consider what happens when data leaves their access-control boundary.

These protections matter. A synchronization engine should know which authenticated channel delivered a card, verify message integrity and enforce the caller's permissions. CardDAV ETags can distinguish resource versions, while WebDAV synchronization tokens can enumerate collection changes.

Those receipts stop at different boundaries.

An authenticated envelope can prove that a message arrived intact from a credential under a trust configuration. It does not prove that the credential holder had authority over every contact field. An ETag can prove which stored representation a client addressed. It does not prove two same-looking telephone properties should merge. A synchronization token can prove which resources changed since a prior token. It does not explain why the new resource contains one email, two emails or no email.

Security improves when these layers are composed without being collapsed. Record the transport principal, authorization decision, resource version and collection token. Then separately record the semantic matching and conflict decision. If the resulting telephone number later reaches the wrong person, the operator can trace whether the error entered at transport, identity matching, property reconciliation, user confirmation or later use.

SOURCE and REV help, but they are not a property ledger

Revision 00 recommends SOURCE when the vitality of the data matters and allows REV to indicate when the card data was last updated. These fields can make a record easier to refresh and compare.

They cannot carry every property-level provenance fact. One card may combine a work email from a corporate directory, a mobile number entered by the user and an emergency contact imported from another account. One REV timestamp cannot explain the age of each field. One SOURCE URI cannot say who authorized a specific merge or which values were deleted.

This is not an argument to turn vCard into an event-sourcing protocol. A portable contact record should remain compact. It is an argument to avoid demanding that portability format serve as the complete audit system.

The application that performs sensitive merges should keep more evidence than the interchange object needs. The application that merely displays a received card may need less. Local responsibility should scale with the consequence of the action.

A practical receipt chain for contact synchronization

An operator can preserve the draft's interoperability benefits with a simple layered record.

First, hash each input vCard exactly as received and record the transport principal, security result, collection identifier, ETag or sync token and receipt time. Second, record why the cards were placed in one reconciliation set: equivalent UID, explicit user selection or a local heuristic. Third, enumerate mandatory property matches separately from discretionary matches.

For every discretionary match, save the compared values before and after normalization, original PIDs, CLIENTPIDMAP resolution, heuristic version, confidence and policy result. For every conflict, record whether the engine copied, retained, overwrote, deleted or quarantined each value. If global context is simplified, preserve the old-to-new mapping and both object hashes.

Finally, do not treat synchronization success as contact correctness. A subsequent action has its own receipt: a call connected, a message bounced, a user confirmed an address, an administrator reversed the merge. Operational feedback can improve the next decision, but it should not rewrite the earlier evidence.

This chain does not require the IETF format to become an authority system. It lets the format remain a compact coordination artifact while the operator remains responsible for local power.

The best format says where its answer ends

Revision 00 is strongest where it is deterministic and honest where it cannot be. Equivalent UID values force a record match. Equivalent global PID values force a property match. Unmatched cards and differently named properties create prohibitions. Other same-name cases remain discretionary. Global-context simplification remains unspecified.

That division is not weakness. It is a map of authority.

The common format owns syntax and the narrow identity edges it defines. The synchronization engine owns heuristics. The application owns conflict policy. The operator owns deployment and audit. The user or institution owns the decision to act on the contact. Reality supplies the final answer about whether the information was correct.

A converged vCard is therefore a valuable state receipt. It can show what the system currently believes and how future synchronization should recognize several values. It cannot, without external evidence, show that every discretionary merge was justified or that the compact record preserves the full source history.

The practical rule is simple: serve the compact card, but retain the merge receipt. Interoperability needs the first. Accountability begins with the second.

Sources