Summary

  • RFC 9982 makes JSContact's uid optional in version 2.0 and forbids a converter from generating a v2 uid when the source vCard has no UID.
  • An identifier makes a record referenceable within a defined data model. It does not by itself prove personal identity, a current relationship, source provenance, consent, ownership or authority to modify a contact.

RFC 9982 is a small change with a large evidentiary lesson. Earlier JSContact rules required uid on every Card. That fit address-book synchronization systems that need a durable handle, but it conflicted with vCard, whose UID is optional, and with representations such as RDAP that may have no need for that handle. The earlier conversion rule could generate a value for a vCard with no UID, but did not require different implementations—or repeated conversions by one implementation—to generate the same value. A field created to satisfy structure could therefore be mistaken for a fact about the represented entity.

Version 2.0 restores the boundary. A Card without uid is valid unless another specification says otherwise. It cannot be named as a member through members, nor be placed in another Card's relatedTo relation. The rule is careful: it does not call the card false, anonymous, obsolete or unusable. It says that this particular record lacks the stable handle required for those machine-readable links. That is a narrower and safer conclusion.

The conversion rule is where the discipline becomes operational. When a source vCard has no UID, an implementation converting it to JSContact 2.0 or later must not generate uid. For version 1.0 it still had to generate a value, with implementation-specific generation and a recommendation—not a guarantee—of repeatability. RFC 9982 explains why that was dangerous: an unaware recipient might use an ephemeral value in membership or relationship fields and create invalid links between cards. The version bump prevents a formatting convenience from silently becoming relational authority.

That distinction matters well beyond contact software. There are at least seven separate claims hiding behind the phrase “this is the same contact”: the source record is byte-for-byte the same; a local key is stable; two records refer to the same real-world person or organization; a relationship remains current; the source was allowed to make that assertion; the recipient is allowed to join or update the records; and the resulting change was reconciled correctly. RFC 9982 governs a narrow part of record shape and conversion. It supplies none of the other claims.

Even a present uid has bounded meaning. It is a string in a Card object, not a cryptographic credential, verified legal name, account-recovery factor, proof of consent, or universal public identifier. A version marker says which JSContact rules apply. The newly registered vCard JSCOMPS parameter corrects registry completeness for a conversion feature; it does not certify that a conversion preserved semantic intent. CardDAV and JMAP Contacts may rely on identifiers for their protocols, while another representation may not. Protocol need should be explicit rather than backfilled as identity truth.

Heng Lu's minimum-specification idea helps explain the gain. A portable record format needs enough common structure to exchange data, but it should not pretend that every local relationship and decision has been settled by a string. Running code also provides a useful test: a successful parse, conversion or synchronization job is an event in a pipeline, not conclusive evidence that separate affiliations now describe reality.