Protocol-Specific Profiles for JSContact Fastmail
PO Box 234 Collins St. West Melbourne VIC 8007 Australia rsto@fastmailteam.com
IIT-CNR
Via Moruzzi, 1 Pisa 56124 Italy mario.loffredo@iit.cnr.it
ART calext JSContact This document defines the "JSContact Profiles" registry, an IANA registry for named subsets of JSContact elements. The document aims to facilitate using JSContact in the context of contact data exchange protocols or other use cases in which supporting all JSContact semantics might be inappropriate.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
  • .  Notational Conventions
  • .  JSContact Profiles
    • .  Profile Name
    • .  Profile Version
    • .  Profile Properties
    • .  Supported Properties
  • .  IANA Considerations
  • .  Security Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • .  Example Profile
    • .  Profile Properties Example
    • .  Card Object Example
    • .  IANA Registry Example
    • .  Supported Properties Example
  • Authors' Addresses
Introduction The JSContact contact card data model and format are designed for use in address book applications and directory services. Intended as an alternative to the prevalent vCard data format, JSContact covers vCard core semantics and extensions, and it provides a rich model for personal names, postal addresses, and localization. All JSContact elements are relevant for some contact card use cases, and similar to vCard, implementations are expected to support these elements when exchanging contact card information using protocols such as CardDAV and the JSON Meta Application Protocol (JMAP) for Contacts . In contrast, other protocols and document specifications might require exchanging some contact card information, but not all of what JSContact provides. outlines how JSContact implementations may ignore unknown JSContact elements, but this only applies to future extensions of ; they are still expected to implement all elements of the core specification. Also, the extensibility of JSContact and the requirement to preserve arbitrary contact elements might not be adequate for some protocols. To make use of JSContact under these circumstances, this document defines a new IANA registry for JSContact that allows registration of named subsets of JSContact elements. These subsets are referred to as "JSContact profiles" and are meant to bring the following benefits:
  • Protocol designers might be encouraged to use JSContact rather than coming up with their own contacts format. This facilitates cross-protocol data exchange and migration.
  • Different protocols use the same IANA registry to express which JSContact elements they support. This facilitates understanding their commonalities and reusing existing profiles.
  • A central registry provides implementors of JSContact libraries with a consistent format documenting which profile supports what elements rather than having to look up that information from possibly distinctly organized Internet-Drafts.
This document is organized as follows. defines JSContact profiles; discusses the new "JSContact Profiles" registry created by IANA; and illustrates JSContact profiles using an example.
Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The ABNF definitions in this document use the notations of . ABNF rules not defined in this document are defined in (such as the ABNF for DIGIT).
JSContact Profiles A JSContact profile is a named and versioned set of JSContact elements, such as properties, types, and values. The JSContact elements MUST be registered in the IANA "JSContact" registry group . A profile MAY define additional restrictions for these elements as outlined in , but a profile MUST NOT loosen restrictions. This document creates an IANA registry for JSContact profiles (see ). A JSContact object complies with a profile if all its properties are in the set of properties defined by that profile and the property values comply with the profile restrictions for that property. A JSContact object MAY comply with multiple profiles. Accordingly, this document does not specify any means for JSContact data to communicate which profiles it complies with, e.g., it does not define a "profile" property for the Card object. All properties and values of a JSContact object that complies with a profile MUST also be valid (). Handling JSContact data that is valid but that does not comply with the expected profile is protocol-specific. This document deliberately does not define such non-compliant data as invalid. Profile designers decide on their own strategies for handling non-compliant data, one of which may be to reject it as invalid. JSContact data that complies with a profile may still not be valid in the context of that protocol; the protocol specification MAY define additional restrictions that a profile cannot express. defines how to name a JSContact profile; defines how to version it; defines how to specify the properties supported by that profile; and describes how to determine the supported properties.
Profile Name A JSContact profile has a unique name. The name MUST only contain ASCII lowercase alphabetic and numeric characters, optionally separated by hyphens. It MUST start with an alphabetic character, and it MUST be of at least 1 character and at most 255 characters in size. Formally, it MUST be a valid "profile-name" defined in .
ABNF Rule for JSContact Profile Name profile-name = lalpha *( ["-"] lalpha / DIGIT ) ; at most 255 characters in size lalpha = %x61-7A ; a-z
Profile Version A JSContact profile has a current version, and each profile is versioned independently. The version MUST be a positive integer, and it MUST increase whenever the profile properties (see ) change. The initial version value is 1.
Profile Properties A profile defines a list of property entries that together determine the set of properties supported by that profile, as described in . The list MUST NOT be empty. Each property entry consists of the following elements:
Property Name:
This is the name of the JSContact property that this entry refers to. This MUST be a property name registered in the "JSContact Properties" registry. A property name MAY occur multiple times in the property entry list if the profile-specific restrictions for that property cannot be expressed with a single entry, but such multiple entries MUST NOT result in conflicting restrictions for the same property. This field MUST NOT be empty.
Property Context:
This is a comma-separated list of JSContact object types that support this property in this profile. Each of these types MUST also be listed in the Property Contexts for this property in the "JSContact Properties" registry, but a profile MAY only support the property in a subset of these contexts. This field MUST NOT be empty.
Restricted Attributes:
This restricts the attributes of the property. This specification only defines how to restrict the attributes such that a property becomes mandatory in the listed Property Contexts, despite the property originally being defined to be optional in the same contexts. The verbatim value "mandatory" (without quotes) indicates that it is mandatory in this profile; the absence of any value indicates that this profile does not restrict the property attributes of the original definition.
Restricted Property Type:
This restricts the property value type in the listed Property Contexts. It allows a profile to restrict the allowed types to the original type definition such that future changes to JSContact do not extend the allowed types of the property for this profile, and it allows a profile to restrict the allowed types to a subset of the original type definition. The absence of any value indicates that this profile does not restrict the property value type of the original definition or any future extensions of the value type. If set, the restricted value type MUST exactly match the original definition at the time when the profile is defined, or the original value type MUST contain some type signature in the form "A|B" and the restricted value type MUST resemble the original except that some of the original "A|B" forms now only allow a subset of the original choices. Restricted property types MUST NOT redefine the "defaultType" attribute (); the rules about when to set the "@type" property () of the original type definition still apply. As an example of restricting the type definition to prevent future type extensions in the profile, one might restrict the type definition of the "addresses" property of the Card object to "Id[Address]", which matches the original definition as of this writing. As an example of restricting the type to a subset of the original value, one might want to restrict the "date" property of the Anniversary object to only allow partial dates as values. To do so, the original value type "PartialDate|Timestamp" can be restricted to "PartialDate". Note that the original value type need not be exactly in form "A|B". For example, the type signature "Id[A|B|C]" could be restricted to any of "Id[A|B]", "Id[A|C]", "Id[B|C]", "Id[A]", "Id[B]", "Id[C]", and the type signature "(A|B)[]" could be restricted to one of "A[]" or "B[]".
Restricted Enum Values:
This restricts the enumerated values defined for this property to a subset of those values. The values MUST be listed in the "JSContact Enum Values" registry for this property and context. Allowed values are separated by a comma; the absence of any value indicates that all enumerated values are allowed. A profile MAY exclude the default enumerated value of a property, in which case all instances of the object MUST have this property set to one of the allowed values.
Restricted PatchObject:
This restricts the PatchObject value of this property such that each JSON Pointer key in the PatchObject MUST consist of exactly one JSON Pointer reference token (). For example, with this restriction, the "localizations" property of the Card object can only patch properties of the Card object by replacing their values entirely. The verbatim value "yes" (without quotes) indicates that this profile restricts PatchObject keys to a single token; the absence of any value indicates that it does not restrict them. This MUST NOT be set to "yes" if the property value type is not a PatchObject.
All profiles MUST support "@type" and "version"; therefore, profiles MUST NOT include entries for these properties.
Supported Properties The supported properties of a JSContact profile are determined by the profile's property entries and the contents of the IANA "JSContact Properties" registry, which are referred to here as "IANA-registered properties" for short. The "version" property of the Card object and the "@type" property of any object type are always supported. A Card object complies with the profile if all its properties are part of the supported properties and all property values are valid according to the restrictions defined in the applicable property entries. A PatchObject MUST NOT patch properties that are not supported in that profile. The following describes the steps to determine the supported properties:
  1. Initialize the set with all properties of the Card object for which a property entry contains "Card" in the Property Context of the profile. If no such entry exists, then initialize the set with all IANA-registered properties of the Card object.
  2. For every property in the set having either an object type as the value type or a list, map, or union of object types, add all properties for which a property entry contains those object types in the Property Context of the profile. If no such property entry exists, then add all IANA-registered properties for the object types.
  3. Repeat the previous step until all object types that are value types of properties in the set have been considered.
describes how to determine the supported properties of the example profile in .
IANA Considerations IANA has created the "JSContact Profiles" registry within the "JSContact" registry group. The purpose of this new registry is to register profiles for JSContact data. The registry policy to add an entry to this registry is "Specification Required" ; this applies to defining a new profile name or version. The registry policy to update an existing profile is "Expert Review"; this applies to updating the references of an entry. The change controller is the IETF. An entry in this registry consists of the following, all of which MUST be set:
Name:
This is the name of the profile. This field is immutable after creation. The name MUST be unique among all registered profiles and MUST comply with the definitions in .
Version:
This is the version number of the profile. This field is immutable after creation. It MUST comply with the definitions in .
Reference:
This refers to the specification of the protocol or use case for which this profile applies. The reference MUST include the section number or section name that defines or updates the property entries for this profile, as defined in .
Designated experts assert that all proposed assignments are valid according to the definitions in this document. For example, they check that:
  • the profile name is unique,
  • the entries in the profile entries are syntactically valid,
  • only known property names are referred to,
  • type restrictions do not incorrectly alter the type of a property, and
  • the version number increases.
On the other hand, designated experts do not decide the contents of the profile as long as the assignments are valid. The decision whether to register a new profile name or register a new version for an existing profile depends on the scope of the proposed profile. A new profile name is recommended if the profile is introduced in the context of an application or protocol for which no JSContact profile is already registered or if the proposed profile properties or restrictions substantially differ from existing profiles for that context. A new version is recommended if the profile context does not change and multiple implementations of the current profile will also support the new version. The profile version of the new entry for an already-registered profile by that name has to be higher than the last registered version for that profile. Existing registry entries are preserved. This document does not define any initial contents for the "JSContact Profiles" registry.
Security Considerations This document does not provide any new security considerations. The security considerations in apply.
References Normative References JSContact IANA Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] JavaScript Object Notation (JSON) Pointer JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JSContact: A JSON Representation of Contact Data This specification defines a data model and JavaScript Object Notation (JSON) representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable, and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. Two additional specifications define new vCard elements and how to convert between JSContact and vCard. Informative References vCard Format Specification This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK] CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK] Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. JSON Meta Application Protocol (JMAP) for Contacts This document specifies a data model for synchronising contact data with a server using the JSON Meta Application Protocol (JMAP).
Example Profile This section provides an example of a JSContact profile and illustrates how a JSContact Card complies with that profile. The properties of the example profile are defined in . The profile describes contact cards that can only contain:
  • Contact cards for individuals and organizations, but no other kinds such as groups or devices.
  • Full postal address lines, but no address components or any other property of the Address object type. The value type of the "addresses" property is pinned to its original definition, so that future JSContact extensions of that type do not become part of the profile.
  • Full names and name components, but no other properties of the Name object type.
  • Email addresses, where all properties of the EmailAddress object are supported.
  • Anniversaries for birthdays, and only having "date" property values of type PartialDate, not Timestamp.
  • Localizations, with the restriction that the PatchObject must only patch properties of the Card object.
An example of JSContact data that complies with this profile is shown in . An example of its fictive IANA registration is shown in . This profile is just for illustration; it is not registered with IANA. describes how to determine the supported properties for that profile.
Profile Properties Example The following entries define properties of that profile. Entry elements with empty values are omitted:
Property Name:
addresses
Property Context:
Card
Restricted Property Type:
Id[Address]
Property Name:
anniversaries
Property Context:
Card
Property Name:
emails
Property Context:
Card
Property Name:
kind
Property Context:
Card
Restricted Enum Values:
individual,org
Property Name:
localizations
Property Context:
Card
Restricted PatchObject:
yes
Property Name:
name
Property Context:
Card
Property Name:
full
Property Context:
Address
Restricted Attributes:
mandatory
Property Name:
date
Property Context:
Anniversary
Restricted Property Type:
PartialDate
Property Name:
kind
Property Context:
Anniversary
Restricted Enum Values:
birth
Property Name:
components
Property Context:
Name
Property Name:
full
Property Context:
Name
Property Name:
kind
Property Context:
NameComponent
Property Name:
value
Property Context:
NameComponent
Card Object Example The following Card object complies with the example profile: { "@type": "Card", "version": "1.0", "name": { "components": [ { "kind": "given", "value": "Hayao" }, { "kind": "surname", "value": "Miyazaki" } ] }, "addresses": { "a1": { "full": "71 Cherry Court, Somewhere, 123SO, UK" } }, "emails": { "e1": { "address": "hayao@example.com" } }, "anniversaries": { "a1": { "kind": "birth", "date": { "month": 3, "day": 4 } } }, "localizations": { "jp": { "name": { "components": [ { "kind": "surname", "value": "宮崎" }, { "kind": "given", "value": "駿" } ] } } } } Note that:
  • The Address, Card, Name, and NameComponent object values only contain properties for which a property entry exists in the profile.
  • The EmailAddress object contains the "address" property. This is allowed because the profile contains a property entry for the "emails" property of the Card object, but it does not define entries for the EmailAddress object properties. Consequently, all properties of the EmailAddress object can be set.
  • The "full" property of the Address object is set. It is the only property allowed to be set in that profile for Address, and the "full" property is mandatory for this profile.
  • The "kind" property of the NameComponent object is set to "surname" and "given". Since the profile does not restrict the enumerated values of this property, all valid NameComponent "kind" property values are supported.
  • The "kind" property of the Card object is not set. The profile restricts the enumerated values of this property to "individual" and "org". Since "individual" is the default value for this property, there is no need to set it.
  • The "date" property of the Anniversary object is restricted to be of type PartialDate in this profile. Because PartialDate is the default type for this property, there is no need to the set the "@type" property of the PartialDate object.
IANA Registry Example The following would be registered at IANA if this were a real profile:
Name:
jscontact-simple-example
Version:
1
Reference:
This document,
See for the definition of each registry item.
Supported Properties Example The following illustrates how to determine the supported properties of the example profile in this appendix, according to the steps defined in :
  1. We initialize the set of supported properties with all profile properties for which the Property Context includes the Card object. The set now includes the following properties:
    • Card.addresses
    • Card.anniversaries
    • Card.emails
    • Card.kind
    • Card.localizations
    • Card.name
  2. Next, we determine which of the properties in the current set have an object type as the value type. These are the Card.addresses, Card.anniversaries, Card.emails, and Card.name properties, so we need to inspect the object types Address, Anniversary, EmailAddress, and Name. The "addresses" entry restricts the value type of that property to "Id[Address]", which matches its original definition, but any future type extension would still require us only to inspect the Address type.
  3. For the Address object type, the profile has an entry for the "full" property, which contains the Address object in the Property Context, so we add that and only that to the set of supported properties. It now contains:
    • Address.full
    • Card.addresses
    • Card.emails
    • Card.kind
    • Card.localizations
    • Card.name
    The value type of the Address.full property is not an object type, so we need not consider a new object type to inspect. The remaining object types to inspect are the Anniversary, EmailAddress, and Name objects.
  4. For the Anniversary object type, the profile explicitly lists the "kind" and "date" properties, so we add them to the set of supported properties. It now contains:
    • Address.full
    • Anniversary.date
    • Anniversary.kind
    • Card.addresses
    • Card.emails
    • Card.kind
    • Card.localizations
    • Card.name
    The newly added Anniversary.date property has object value type PartialDate, so we add that to the list of object types to inspect. The entry restricts the type of that property to only be of that type, so we do not add the object value type Timestamp. The remaining object types to inspect are the EmailAddress, Name, and PartialDate objects.
  5. For the PartialDate object type, the profile does not contain any entry where the Property Context contains the PartialDate object. Instead, we add properties from the "JSContact Properties" registry where the Property Context includes the PartialDate object. The set of supported properties now contains:
    • Address.full
    • Anniversary.date
    • Anniversary.kind
    • Card.addresses
    • Card.emails
    • Card.kind
    • Card.localizations
    • Card.name
    • PartialDate.calendarScale
    • PartialDate.day
    • PartialDate.month
    • PartialDate.year
    None of the newly added properties have object value types. The remaining object types to inspect are the EmailAddress and Name objects.
  6. For the EmailAddress object type, the profile does not contain any entry where the Property Context contains the EmailAddress object. Instead, we add properties from the "JSContact Properties" registry where the Property Context includes the EmailAddress object. The set of supported properties now contains:
    • Address.full
    • Anniversary.date
    • Anniversary.kind
    • Card.addresses
    • Card.emails
    • Card.kind
    • Card.localizations
    • Card.name
    • EmailAddress.address
    • EmailAddress.contexts
    • EmailAddress.label
    • EmailAddress.pref
    • PartialDate.calendarScale
    • PartialDate.day
    • PartialDate.month
    • PartialDate.year
    None of the newly added properties have object value types. The remaining object type to inspect is the Name object.
  7. For the Name object type, the profile explicitly lists the "components" and "full" properties, so we add them to the set of supported properties. It now contains:
    • Address.full
    • Anniversary.date
    • Anniversary.kind
    • Card.addresses
    • Card.emails
    • Card.kind
    • Card.localizations
    • Card.name
    • EmailAddress.address
    • EmailAddress.contexts
    • EmailAddress.label
    • EmailAddress.pref
    • Name.full
    • Name.components
    • PartialDate.calendarScale
    • PartialDate.day
    • PartialDate.month
    • PartialDate.year
    The newly added Name.components property has object value type NameComponent, so we add that to the list of object types to inspect.
  8. For the NameComponent object type, the profile does not explicitly list any property. Instead, we add properties of the "JSContact Properties" registry where the Property Context includes the NameComponent object. The set of supported properties now contains:
    • Address.full
    • Anniversary.date
    • Anniversary.kind
    • Card.addresses
    • Card.emails
    • Card.kind
    • Card.localizations
    • Card.name
    • EmailAddress.address
    • EmailAddress.contexts
    • EmailAddress.label
    • EmailAddress.pref
    • NameComponent.kind
    • NameComponent.phonetic
    • NameComponent.value
    • PartialDate.calendarScale
    • PartialDate.day
    • PartialDate.month
    • PartialDate.year
    None of the newly added properties have object value types, and there are no remaining object types to inspect. This determines the set of supported properties by that profile, in addition to the "Card.version" and "@type" property that are always supported.
Authors' Addresses Fastmail
PO Box 234 Collins St. West Melbourne VIC 8007 Australia rsto@fastmailteam.com
IIT-CNR
Via Moruzzi, 1 Pisa 56124 Italy mario.loffredo@iit.cnr.it