Summary

  • RFC 10050 defines a JSContact profile as a named and versioned set of restrictions on registered properties, types and values. A profile may narrow JSContact, never relax its base rules, and one card may comply with several profiles at once.
  • The card contains no universal profile declaration. The surrounding protocol must say which profile applies, how its name and version are conveyed, and what additional validity rules remain. Profile compliance is therefore evidence, not an acceptance receipt.
  • Registry identity is durable: a profile name and version identify immutable content, old versions remain visible, and later registrations receive new versions. Yet Designated Experts review registry form and reference fitness rather than certifying the profile's substantive design.

Consider a contact card that passes two independent validators. One reports compliance with a profile used by a directory exchange. The other reports compliance with a narrower profile used by an address-book synchronisation service. Both can be right. The same card can inhabit the intersection of two permitted subsets.

Now ask the operational question: may a particular protocol message carrying that card be accepted?

The validators have not answered it. The message could have claimed the wrong profile version. Its protocol could forbid a property that the profile permits. The receiver could require a profile that was never declared, or apply a negotiated profile whose identity is carried outside the card. The card's JSON may be valid JSContact and compliant with a registered profile while the protocol exchange is still invalid.

That distinction is the centre of RFC 10050, the September 2026 Proposed Standard for JSContact profiles. It is not another contact-data format. It is a way to name restricted uses of the format without mistaking the name for the complete protocol contract.

A subset with a durable identity

RFC 9553 defines the JSContact data model and its Card object. RFC 10050 begins from the observation that a generic model usually permits more variation than a particular application wants. A profile can make optional properties mandatory, prohibit otherwise valid properties, restrict allowed types or select narrower values. It can only tighten the base specification. It cannot turn invalid JSContact into valid JSContact.

The profile is identified by a case-sensitive name and a positive integer version in the IANA JSContact Profiles registry. Taken together, those two fields act as the stable key. Once registered, the content associated with a name-version pair is not revised in place. A changed profile receives a greater version, while earlier versions stay in the registry.

That immutability is more than archival neatness. If an implementation says it validated example version 2, operators need that statement to mean the same thing after version 3 appears. Quietly replacing the reference behind version 2 would dissolve the evidence supplied by logs, conformance reports and stored messages. Registry history is therefore part of protocol memory.

Compliance has recursive edges

The obvious reading of a profile is a list of top-level properties. RFC 10050 requires more care. A property can contain nested objects, and the types allowed for one property can introduce further properties below it. The set of supported properties is consequently recursive: validators must follow the permitted property/type graph to its closure.

This matters when systems implement a profile as a shallow allow-list. A top-level property may be allowed while a nested property or type is outside the profile. Conversely, rejecting every nested field not printed beside the top-level rule can exclude fields that are reachable through an allowed type. RFC 6901 JSON Pointers are used to identify profile elements precisely, but a correct pointer does not replace traversal of the model.

The result is a small but important implementation truth: profile compliance is computed, not stamped. A validator needs the base JSContact rules, the exact registered profile version and a recursive account of the property structures that version admits.

No profile label inside the card

RFC 10050 deliberately does not add a property to Card that announces profile membership. Nor does it define one universal way to carry a profile name or version. The embedding protocol owns that mechanism.

This avoids a misleading self-assertion. Because one card may satisfy multiple profiles, a single in-object label would either discard valid information or invite an array of claims whose relevance depends on context. More fundamentally, the sender's assertion is not the receiver's validation. The protocol already has to define negotiation, required versions, error behaviour and any rules beyond the profile; it should also define how the applicable profile is selected and conveyed.

The custody chain therefore has distinct records. The message needs evidence of which profile the protocol expected. The validator needs the immutable name-version definition it evaluated. The receiver needs the result of base JSContact validation, profile validation and protocol-specific checks. Collapsing those into a boolean called valid destroys the very boundary the RFC preserves.

The registry does not approve the design

New JSContact profile registrations use the Specification Required policy described by RFC 8126. Updating a reference is subject to Expert Review, and the IETF is the change controller. RFC 10050 asks Designated Experts to check practical registry matters: the identifier is unique and syntactically sound, referenced properties and types are known, the specification is stable enough to evaluate, and a new version advances the version number.

It also draws a limit. Experts are not required to assess the actual content of a profile. Registration is not an endorsement that the chosen subset is secure, complete or suitable for a particular deployment. An entry says that a durable specification can be found under a stable identity. Protocol owners still carry responsibility for the policy they attach to it.

That caveat deserves attention because registries often acquire social authority beyond their formal role. A registered profile can be interoperable in the narrow sense that two implementations retrieve the same definition, yet still make poor privacy choices or omit a field essential to a sector. RFC 9553 warns that contact data can be sensitive and that data minimisation matters. A profile's restrictions may help minimisation, but a registry row does not perform the risk assessment.

A dated view of an empty control surface

At the time of this review, the IANA JSContact registry page displayed its JSContact Profiles section with no registrations and with Designated Experts not yet assigned; the page showed a last-updated date of 28 May 2026 and still cited an Internet-Draft reference. RFC 10050 was published later, in September 2026.

That is a dated snapshot, not evidence of neglect. Publication and registry updates can move on different schedules. It is nevertheless an operational reason to capture the registry state used by a deployment rather than assume that the current page, the RFC and local software all describe the same moment.

An implementation claiming support for a profile should be able to produce a custody record: profile name and version; a digest or archived copy of the referenced specification; retrieval time; base JSContact version; validator version; recursive property-set result; the profile selection conveyed by the protocol; and every additional protocol rule applied. If the registry changes later, the old decision remains reconstructible.

Sources