JSContact Version 2.0: A JSON Representation of Contact Data Fastmail
PO Box 234 Collins St. West Melbourne VIC 8007 Australia rsto@fastmailteam.com
ART calext JSContact addressbook contacts cards This document defines version "2.0" of JSContact. It defines the uid property of a Card object to be optional, rather than mandatory, as defined previously in version "1.0". All other definitions of JSContact version "1.0" remain as defined in RFC 9553. This document updates RFC 9555 by redefining how to convert the now optional uid property from and to vCard. It also registers the vCard JSCOMPS parameter at IANA, which was defined but not registered in RFC 9555.
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 Version 2.0
  • .  Redefined uid Property
  • .  Redefined Conversion Rule for the uid Property
  • .  Other Changes
  • .  IANA Considerations
    • .  Update to the JSContact Version Registry
    • .  Update to the JSContact Properties Registry
    • .  Update to the vCard Parameters Registry
  • .  Security Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • Author's Address
Introduction JSContact defines the Card object uid property, a mandatory property that contains a unique identifier for the entity represented by that contact card. For the same purpose, the vCard contact format defines the UID property, an optional property of a vCard instance. Throughout the rest of this document, the term uid (all lowercase) denotes the JSContact uid property, and the term UID (all uppercase) denotes the vCard UID property. The uid property being defined as mandatory in JSContact has shown to be applicable for some use cases but turned out to be an issue in other contexts.
  1. A stated goal of JSContact is to be compatible with the semantics of the vCard data format (). But defines the UID property of a vCard to be optional, and consequently, the semantics of JSContact and vCard differ for such a crucial common element.
  2. Address book synchronization protocols, such as CardDAV and JMAP for Contacts, require the uid property. But other protocols, such as RDAP, have no use for it. JSContact should not require protocols to generate unique identifiers when they are irrelevant or even detrimental to the use case.
  3. Converting vCards having no UID property to JSContact is especially problematic: requires implementations in this case to generate a unique identifier during conversion but does not require it to be the same across implementations or even one implementation converting the same Card multiple times. A recipient being unaware that the uid property value of such a Card object is ephemeral might refer to it in the members property or relatedTo property of another Card object, introducing invalid relations between contact cards.
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 either (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT) or .
JSContact Version 2.0 This document redefines the uid property of a Card object to become optional. Other than that, the property definition is left unchanged. This change requires the major version of JSContact to change, so this document defines the JSContact version to become "2.0". For further information about versioning JSContact data, see . Implementations MUST create JSContact data that complies with the definitions of version "2.0" (or some later registered version) and MUST set the version property of the JSContact Card object to that version. They MUST NOT reject a Card object without the uid property as invalid unless specified differently in another document or unless the Card version property has value "1.0". As any valid version "1.0" JSContact Card is also valid according to version "2.0", there is no need to migrate existing JSContact data. This document does not redefine the vCard UID property.
Redefined uid Property This document redefines the type signature of the uid property, originally defined in . OLD:
uid: String (mandatory).
NEW:
uid: String (optional).
The remaining property definition is left unchanged, with the following additional paragraph:
A Card without an uid property cannot be referred to as a group member in the members property () or put in relation to another Card object in the relatedTo property ().
Redefined Conversion Rule for the uid Property This document redefines how to convert the Card uid property from vCard, originally defined in . The new conversion rule is as follows: Implementations that convert a vCard without a UID property () to a Card of version "2.0" or higher MUST NOT generate a unique identifier as a value for the uid property (). When converting a vCard without a UID property to JSContact version "1.0", implementations MUST generate a value for the uid property. How to generate unique identifiers is implementation-specific. Implementations SHOULD generate the same value when generating the same Card multiple times, but as describes, this still cannot prevent interoperability issues. Consequently, implementations SHOULD NOT convert to version "1.0" Card objects.
Other Changes This document also registers the JSCOMPS parameter in the IANA "vCard Parameters" registry. The parameter was defined in but mistakenly not registered at IANA.
IANA Considerations
Update to the JSContact Version Registry IANA has updated the "JSContact Version" registry, originally created in , by adding the following record: JSContact Version Registry
Major Version Highest Minor Version Reference
2 0 RFC 9982
Update to the JSContact Properties Registry IANA has updated the "JSContact Properties" registry, originally created in : In the "Reference/Description" column of the uid property, a reference to of this document has been added.
Update to the vCard Parameters Registry IANA has updated the "vCard Parameters" registry within the "vCard Elements" registry group by adding the following entry: vCard Parameters Registry
Namespace Parameter Reference
JSCOMPS
Security Considerations This document does not provide new security considerations. The security considerations of apply.
References Normative References 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] 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] 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. JSContact: Converting from and to vCard This document defines how to convert contact information between the JSContact and vCard data formats. It defines conversion rules for every JSContact and vCard element registered at IANA at the time of publication. It also defines new JSContact properties as well as vCard properties and parameters, to support converting arbitrary or unknown JSContact and vCard elements. Informative References 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] JSON Responses for the Registration Data Access Protocol (RDAP) This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. 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).
Author's Address Fastmail
PO Box 234 Collins St. West Melbourne VIC 8007 Australia rsto@fastmailteam.com