| RFC draft-ietf-calext-jscontact-profiles-11 | JSContact Profiles | December 2025 |
| Stepanek & Loffredo | Expires 21 June 2026 | [Page] |
This document defines JSContact profiles, an IANA registry for named subsets of JSContact elements. It aims to facilitate using JSContact in context of contact data exchange protocols or other use cases, in which supporting all of JSContact semantics might be inappropriate.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 June 2026.¶
Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The ABNF definitions in this document use the notations of [RFC5234]. ABNF rules not defined in this document are defined in [RFC5234] (such as the ABNF for DIGIT).¶
The JSContact [RFC9553] 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 [RFC6350] 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 [RFC6352] and JMAP for Contacts [RFC9610].¶
In contrast, other protocols and internet standards might require exchanging some contact card information, but not all of what JSContact provides. Section 1.7.4 of [RFC9553] outlines how JSContact implementations may ignore unknown JSContact elements, but this only applies to future extensions of [RFC9553]; 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 for registering named subsets of JSContact elements. These subsets are referred to as "JSContact profiles" and are meant to bring the following benefits:¶
This document is organized as follows: Section 3 defines JSContact profiles, Section 4 illustrates JSContact profiles by example, Section 5 summarizes the relevant information for IANA to establish the JSContact Profiles registry.¶
A JSContact profile is a named and versioned set of JSContact properties, value types and values. These JSContact elements MAY be further restricted by the profile, but a profile can not loosen restrictions. For example, a profile can define an originally optional property to become mandatory, but it can not make a mandatory property become optional.¶
The JSContact elements MUST be registered in the IANA JSContact registry. A JSContact extension MAY define both a new profile and new properties or other elements, as long as they are registered at the same time. A JSContact profile MUST be registered at IANA (see Section 5). Section 3.1 defines how to name a JSContact profile, Section 3.2 defines how to version it, Section 3.3 defines how to specify the properties supported by that profile.¶
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 can comply with multiple profiles, even with profiles that weren't defined at the time when the JSContact data was created. 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 (Section 1.7 of [RFC9553]). 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.¶
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 Figure 1.¶
profile-name = LALPHA *( ["-"] LALPHA / DIGIT )
; at most 255 octets in size
LALPHA = %x61-7A ; a-z
A JSContact profile has a current version, each profile is versioned independently. The version MUST be a positive integer and it MUST increase whenever the profile properties (Section 3.3) change. The inital version value is 1.¶
If this versioning scheme is not adequate for protocol designers making use of JSContact profiles, then an alternative approach is to register a new JSContact profile for each new version.¶
A profile defines a list of property entries that together determine the set of properties supported by that profile, as described in Section 3.4. The list MUST NOT be empty.¶
Each property entry consists of the following elements:¶
This restricts the property value type in the listed property contexts, even though the property was originally defined with a less restrictive type definition. If set, the original value type MUST contain some type signature in 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 can not redefine the "defaultType" attribute [RFC9553] (Section 1.3.3), the rules when to set the "@type" property [RFC9553] (Section 1.3.4) of the original type definition still apply.¶
For example, 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)[]" to one of "A[]" or "B[]".¶
All profiles MUST support "@type" and "version", and therefore profiles MUST NOT include entries for these 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 is here referred to 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:¶
Appendix A describes how to determine the supported properties of the example profile in Section 4.¶
This section provides an example for a JSContact profile and illustrates how a JSContact Card complies with that profile. Appendix A describes how to determine the supported properties for that profile. The example profile is defined the same as if it would be registered in the IANA JSContact Profiles registry. See Section 5 for the exact meaning of each registry item. This profile is just for illustration, it is not registered at IANA.¶
The following assignments would be registered at IANA if this were a real profile:¶
The following table defines the properties of that profile. This profile does not specify any "Restricted Property Type" and the according column is omitted.¶
| Property Name | Property Context | Restricted Attributes | Restricted Enum Values | Restricted PatchObject |
|---|---|---|---|---|
| addresses | Card | |||
| emails | Card | |||
| kind | Card | individual,org | ||
| localizations | Card | yes | ||
| name | Card | |||
| full | Address | mandatory | ||
| components | Name | |||
| full | Name | |||
| kind | NameComponent | |||
| value | NameComponent |
This profile describes contact cards that can only contain:¶
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"
}
},
"localizations": {
"jp": {
"name": {
"components": [
{ "kind": "surname", "value": "宮崎" },
{ "kind": "given", "value": "駿" }
]
}
}
}
}
¶
Note that:¶
IANA will add the "JSContact Profile" registry to the "JSContact" registry group. The purpose of this new registry is to register profiles for JSContact data. The registry policy to add a new profile to this registry is "Specification Required", while the registry policy to update an existing profile is "Expert Review". The change controller is IETF.¶
Designated experts assert that all proposed assignments are valid according to the definitions in this document, e.g. they check that the profile name is unique, that the entries in the profile entries are syntactically valid, that only known property names are referred to, that type restrictions do not incorrectly alter the type of a property, and that 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.¶
An entry in this registry consists of the following assignments, all of which MUST be set:¶
This document does not define any initial contents for the newly created registries.¶
This document does not provide new security considerations. The security considerations of Section 4 of [RFC9553] apply.¶
The following illustrates how to determine the supported properties of the example profile (Section 4), according to the steps defined in Section 3.4:¶
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 properties:¶
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:¶
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 "EmailAddress" and "Name" objects.¶
For the "EmailAddress" object type, the profile does not contain any entry where the Property Context contains the "EmailAddress" object. Instead, we add properties of the "JSContact Properties" registry where the property context includes the "EmailAddress" object. The set of supported properties now contains:¶
None of the newly added properties have object value types. The remaining object type to inspect is the "Name" object.¶
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:¶
The newly added Name.components property has object value type "NameComponent", so we add that to the list of object types to inspect.¶
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:¶
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.¶