Summary

  • RFC 9553 localizes a Card by selecting a language-tagged PatchObject, copying the base Card without its localizations member and applying every patch to that copy.
  • Whole-patch validation prevents a half-applied localized view, but it does not authenticate the author, approve an identity alias, establish freshness or prove that contact details belong to the named subject.
  • A defensible production record binds the base fingerprint, selected tag, exact patch, authorization, output fingerprint and downstream use instead of treating every rendered language as an independent source of truth.

The second language is not a second record

Suppose a directory shows one executive as “Gabriel García Márquez” in its main view and changes a role label from “novelist” to “escritor” for a Spanish reader. The localized page looks complete. It can be exported, cached and copied into another system. That visual completeness invites a dangerous operational conclusion: there must now be two authoritative records, one per language.

RFC 9553 describes something narrower. A JSContact Card carries a language for its main text and may contain a localizations map. Each key in that map is an RFC 5646 language tag. Each value is a PatchObject containing the alternatives for that language.

The conceptual procedure matters. The consumer first determines a language tag. If the map contains that tag, it creates a copy of the Card without the localizations member, applies the selected PatchObject to the copy, may update the copy's language, and uses the result as the localized variant of the original Card. It does not mint another uid. It does not define a new source record. It does not give the copy an independent revision history.

That is a useful architecture. Common facts can remain in one base object while a name component, title or address receives language-specific presentation. It is also an evidentiary constraint. The localized output is a projection over a particular base and patch. If an operator stores only the output, the two inputs that explain it have disappeared.

Atomic application answers one question

RFC 9553 does not leave patching loose. Its PatchObject is an unordered set whose keys use a subset of JSON Pointer with an implicit leading slash. Intermediate path tokens must already exist. An array member may be replaced but cannot be used to insert or delete one. One pointer cannot be the prefix of another pointer in the same patch set. Values must satisfy the target property's type and restrictions; null can remove only an optional property.

Most importantly, if any patch is invalid, the implementation must reject the whole PatchObject and must not apply a partial result. A French label cannot succeed while a malformed address silently fails inside the same localization. That all-or-nothing rule protects structural coherence.

It proves exactly that. A successful result says the patch was valid against the supplied base object under the implemented JSContact rules. It does not say that a human reviewed the wording, that the alternate script is an official name, that the job title remains current or that the patch author was allowed to change a phone number.

This distinction is easy to lose in automation. “Patch applied” is a parser and transformation event. “Change authorized” is a governance event. “Contact detail belongs to this subject” is an identity and evidence claim. “The person can be reached” is an observed outcome. One green check cannot safely stand for all four.

A path is meaningful only against its base

The RFC illustrates two different localization shapes. One patch replaces the whole top-level name object with a Ukrainian Cyrillic form. Another reaches into titles/t1/name and replaces only the role label, preserving the rest of the t1 object.

The nested version depends on structure. The titles map must exist, the key t1 must still identify the intended title and the final property must accept the new value. RFC 9553 requires Id map keys to survive across versions of one JSContact object precisely because stable keys make concise patching possible.

Yet those keys are local coordinates, not universal identities. The specification warns that the same Id in two maps or two Cards does not imply any semantic relationship. A t1 in titles is not automatically the same object as t1 in another map, another Card or another database.

Version drift therefore matters. A patch that was reviewed against base fingerprint A may still parse against base fingerprint B while targeting a title whose business meaning changed. Or it may fail because the path moved. Neither outcome explains whether the old localized wording should survive. The receipt must bind the patch to the base revision for which it was approved.

The language tag does not make the wording official

RFC 5646 tags coordinate language and, when needed, script or regional information. RFC 9553 uses them as keys and begins the localization process with “determine the language tag.” It does not prescribe a product's complete negotiation policy. It does not decide whether fr-CA falls back to fr, whether a reader prefers one script, or whether a regional form may replace a global one.

Nor does a syntactically correct tag certify the text behind it. A localized organization name might be a verified official name, a conventional translation, a transliteration, an editor's convenience or a fabrication. Those are different claims even when the JSON is impeccable.

For people and institutions, this is where presentation can become identity mutation. A product that invents a translated company name because the route is Chinese has not merely localized chrome; it has asserted a new identity string. RFC 9553 supplies a place to carry an alternative. It does not decide that the alternative is genuine.

A protected-name decision therefore belongs next to the patch record. The evidence might identify an official multilingual source, a subject-approved alias or a reviewed transliteration policy. Without that evidence, the safe conclusion is only that the system can render a language-specific alternative—not that the alternative is an authoritative name.

“Updated” is not a change history

The Card may include created, updated, prodId, version and uid. Each is useful, and each is tempting to overread.

The updated property is the time when data in the Card was last modified. It does not identify which property changed, who made the change, which source was consulted, what the prior value was or whether every localization was reviewed afterward. prodId identifies a product that created the Card; it is not a signer. The JSContact version selects the registered data-model version; it is not a business-data revision. A uid associates the object across systems, address books and views; it does not authenticate the subject or the patch author.

If the base phone number changes, a localization that touches only name can remain mechanically applicable. If the base title changes, an old language-specific titles/t1/name may now be stale even though its path is valid. If the base removes t1, the patch should fail. These three cases require different operator responses, and a single Card-level timestamp cannot reconstruct them.

The useful record is explicit: base fingerprint, base business revision, selected language tag, patch fingerprint, patch provenance, authorization scope, validation result, output fingerprint and render time. When a base update arrives, the system can then decide which localized claims are unaffected, which need review and which are invalid.

The format's own security section refuses the shortcut

RFC 9553 calls contact data privacy sensitive because it can expose identity, location, credentials, employment, interests and social connections. It names eavesdropping, replay, insertion, deletion, modification and on-path attacks. Then it offers a concrete failure: an attacker can use another person's name while inserting the attacker's contact details.

That example is more than generic security boilerplate. A beautifully localized impersonation can be more persuasive than a rough base record. A familiar script, regional title and natural salutation can lower the reader's suspicion while the phone or email belongs to the attacker.

The RFC tells systems with real-world consequences to authenticate received data and ensure that a change comes from an authorized entity. It also states that the document defines only a format; APIs, storage and transmission methods carry the surrounding security work.

So authenticated transport is necessary but incomplete. It may prove which service delivered the Card, not whether that service may edit every field. A valid signature may establish patch origin, not whether the named person approved an alias. Schema validation may reject a malformed pointer, not a plausible lie. Production controls must preserve these separate verdicts.

Registry acceptance coordinates syntax, not truth

RFC 9553 registers version 1.0 and creates IANA registries for JSContact versions, properties, types and enum values. Entries can carry Since Version and Until Version boundaries. This gives parsers and producers a shared vocabulary and lets an implementation state which version it understands.

The registry is an interoperability authority. It can answer whether a property or enum value is defined for a version. It cannot answer whether “Chief Scientist” is a current role, whether an address is safe to disclose, whether a translation is natural or whether a phone number reaches the subject.

That separation matters when a dashboard says “valid JSContact.” It should mean valid under a named model and registry snapshot. It should not be rendered as “verified contact.” The first verdict belongs to syntax and model conformance; the second would require provenance, authorization and observation that the RFC does not provide.

A localized-view receipt is small enough to keep

The operational solution is not another giant contact database. It is a compact lineage record:

  1. identify the base Card by uid, model version and content fingerprint;
  2. record the caller or policy that selected the language tag;
  3. preserve the exact PatchObject and its source or signer;
  4. record all-or-nothing validation against that base;
  5. preserve the output fingerprint and effective time;
  6. attach identity-name approval where a personal or institutional alias changes;
  7. record the downstream consumer and consequential action.

This receipt keeps the rendered view reproducible. It also lets an operator distinguish a broken path, an expired approval, an outdated base and a bad translation without overwriting the original Card.

The objective is not to distrust localization. It is to keep localization's power visible. A language-specific view can improve comprehension and accessibility. Its value rises when the system can explain exactly which facts were inherited, which strings were replaced, who approved them and what outcome was actually observed.

Sources