]> Protocol-Specific Profiles for JSContact Fastmail
PO Box 234 Collins St. West Melbourne VIC 8007 Australia rsto@fastmailteam.com
art calext JSContact This document defines JSContact profiles, a named subsets of JSContact elements that are supported in context of a contact data exchange protocol or other use case. It aims to facilitate using JSContact in contexts where supporting all of JSContact semantics is not appropriate.
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 .
Introduction The JSContact contact card data model and format is designed for use in address book applications and directory services. Intended as an alternative to the prevalent vCard data format, it covers vCard core semantics and extensions, and provides a rich model for personal names, postal addresses and localization. All JSContact elements are relevant for some contact card use case and, similar to vCard, implementations are expected to support these elements when exchanging contact card information using protocols such as CardDAV and JMAP for Contacts. In contrast, other protocols and internet standards might require to exchange some contact card information, but not need 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 of the core specification. Also, for some protocols the extensibility of JSContact and the requirement to preserve arbitrary contact elements might not be adequate. To make use of JSContact under these circumstances, this document defines a new IANA registry for JSContact that allows to register named subsets of JSContact elements. These subsets are referred to as "JSContact profiles", which 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 facilities understanding their commonalities and reuse of existing profiles.
  • A central registry provides implementors of JSContact libraries with a single source of truth 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. summarizes the relevant information for IANA to establish the JSContact Profiles registry. This document does not define any specific JSContact profile.
JSContact Profiles A JSContact profile is a named subset of JSContact elements. The JSContact elements MUST be registered in the IANA JSContact registry. A JSContact extension MAY define both a new profile and new elements, as long as they are registered at the same time. A JSContact object conforms to a profile if all its elements are in the subset defined by that profile.
JSContact Profile Characteristics To define the subset of supported JSContact elements, profiles MAY:
  • Restrict which optional properties of a JSContact object type are allowed to be set.
  • Require optional properties to be set, effectively making them mandatory for that profile.
  • Restrict the enumerated values of a property to a non-empty subset of those values.
  • Restrict the value type signature of a multi-typed property e.g. only allow the value type "A" for a property having value type "A|B".
Profiles MUST NOT:
  • Define mandatory properties to be optional.
  • Replace or expand the value type signature of a property.
  • Change the default type of a multi-typed property.
  • Restrict the allowed values for any value type that is not an enumerated value.
A JSContact profile MUST be registered at IANA (see ).
JSContact Profile Name Every JSContact profile MUST have a unique name. The name MUST only contain ASCII lower case alphabetic and numeric characters, optionally separated by hyphen. Formally, it MUST be a valid "profile-name" defined in the appendix section in .
JSContact Profile Properties The subset of JSContact elements supported by a profile is defined as a list of properties per object type. A JSContact property of an object type is part of this subset if one of the following conditions apply:
  1. It explicitly is listed as supported for that object type in that profile.
  2. It is defined for an object type which is the value type of an explicitly listed property and no properties are listed explicitly for this object type.
  3. It is defined for the Card object and no properties are listed explicitly for the Card object type.
A profile MUST explicitly list at least one property. If at least one property is listed explicitly for an object type, then all mandatory properties of that object type MUST be listed (this is to allow a profile restrict an object type to only its mandatory properties). As an exceptions to this rule the following properties need not be listed, they are always supported:
  • The "@type" of any object type that is supported by this profile.
  • The "version" property of the Card object.
Each property MAY be further restricted as outlined in . The IANA registry template in formally defines the format of property list entries. illustrates this by example.
Example Profile This section provides an example for a JSContact profile. This profile is just for illustration, it is not registered at IANA. The profile name is "jscontact-profile-example". It lists the following properties: The "jscontact-profile-example" profile
Property Name Property Context Restricted to be Mandatory Restricted Enum Values Restricted Property Type
addresses Card
emails Card
kind Card individual
name Card
uid Card
full Address Mandatory
components Name
full Name
kind NameComponent
value NameComponent
This profile describes contact cards that only can contain contact information for individuals, including their full postal address lines (rather than distinct address components) and their full name and distinct name components. It neither supports phonetics nor ordered components for names and addresses. The only additional contact information that is supported in this profile are email addresses. The following Card object conforms to that profile:
IANA Considerations TBD
Security Considerations This document does not provide new security considerations. The security considerations of apply.
References Normative References
ABNF definition for JSContact Profile Name
ABNF Rule for JSContact Profile Name