Protocol-Specific Profiles for JSContact

Status of This Memo

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 25 August 2025.¶

Copyright Notice

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.¶

Table of Contents

1. 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 [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 either [RFC5234] (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT) or [RFC6350].¶

2. Introduction

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 to exchange some contact card information, but not need 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 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: Section 3 defines JSContact profiles. Section 5 summarizes the relevant information for IANA to establish the JSContact Profiles registry. This document does not define any specific JSContact profile.¶

3. 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.¶

4. 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:¶

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:¶

{
  "@type": "Card",
  "version": "1.0",
  "uid": "f5e4cd4f-4283-4d50-bd52-61d07dda971e",
  "name": {
    "components": [
      { "kind": "surname", "value": "Doe" },
      { "kind": "given", "value": "Jane" }
    ]
  },
  "addresses": {
    "a1": {
      "full": "71 Cherry Court, Somewhere, 123SO, UK"
    }
  },
  "emails": {
    "e1": {
      "address": "[email protected]"
    }
  }
}

5. IANA Considerations

TBD¶

6. Security Considerations

This document does not provide new security considerations. The security considerations of Section 4 of [RFC9553] apply.¶

Author's Address