calext R. Stepanek Internet-Draft Fastmail Intended status: Standards Track 21 February 2025 Expires: 25 August 2025 Protocol-Specific Profiles for JSContact draft-stepanek-jscontact-profiles-00 Abstract 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. 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. Stepanek Expires 25 August 2025 [Page 1] RFC draft-stepanek-jscontacJSContactsProfiles February 2025 Table of Contents 1. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. JSContact Profiles . . . . . . . . . . . . . . . . . . . . . 3 3.1. JSContact Profile Characteristics . . . . . . . . . . . . 3 3.2. JSContact Profile Name . . . . . . . . . . . . . . . . . 4 3.3. JSContact Profile Properties . . . . . . . . . . . . . . 4 4. Example Profile . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 Appendix A. ABNF definition for JSContact Profile Name . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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]. Stepanek Expires 25 August 2025 [Page 2] RFC draft-stepanek-jscontacJSContactsProfiles February 2025 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. 3.1. 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. Stepanek Expires 25 August 2025 [Page 3] RFC draft-stepanek-jscontacJSContactsProfiles February 2025 * Require optional properties to be set, effectively making them mandatory for that profile. * Restrict the enumerated values [RFC9553] (Section 1.7.5) 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 Section 5). 3.2. 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 Figure 1. 3.3. 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. Stepanek Expires 25 August 2025 [Page 4] RFC draft-stepanek-jscontacJSContactsProfiles February 2025 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 Section 3.1. The IANA registry template in Section 5 formally defines the format of property list entries. Section 4 illustrates this by example. 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: Stepanek Expires 25 August 2025 [Page 5] RFC draft-stepanek-jscontacJSContactsProfiles February 2025 +==========+===============+============+============+============+ |Property | Property | Restricted | Restricted | Restricted | |Name | Context | to be | Enum | Property | | | | Mandatory | Values | Type | +==========+===============+============+============+============+ |addresses | Card | | | | +----------+---------------+------------+------------+------------+ |emails | Card | | | | +----------+---------------+------------+------------+------------+ |kind | Card | | individual | | +----------+---------------+------------+------------+------------+ |name | Card | | | | +----------+---------------+------------+------------+------------+ |uid | Card | | | | +----------+---------------+------------+------------+------------+ |full | Address | Mandatory | | | +----------+---------------+------------+------------+------------+ |components| Name | | | | +----------+---------------+------------+------------+------------+ |full | Name | | | | +----------+---------------+------------+------------+------------+ |kind | NameComponent | | | | +----------+---------------+------------+------------+------------+ |value | NameComponent | | | | +----------+---------------+------------+------------+------------+ Table 1: The "jscontact-profile-example" profile 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: Stepanek Expires 25 August 2025 [Page 6] RFC draft-stepanek-jscontacJSContactsProfiles February 2025 { "@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": "jane_doe@example.com" } } } 5. IANA Considerations TBD 6. Security Considerations This document does not provide new security considerations. The security considerations of Section 4 of [RFC9553] apply. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, . Stepanek Expires 25 August 2025 [Page 7] RFC draft-stepanek-jscontacJSContactsProfiles February 2025 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, DOI 10.17487/RFC6352, August 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON Representation of Contact Data", RFC 9553, DOI 10.17487/RFC9553, May 2024, . [RFC9610] Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP) for Contacts", RFC 9610, DOI 10.17487/RFC9610, December 2024, . Appendix A. ABNF definition for JSContact Profile Name profile-name = LALPHA *[ ["-"] LALPHA ] LALPHA = %x61-7A | DIGIT ; a-z or 0-9 Figure 1: ABNF Rule for JSContact Profile Name Author's Address Robert Stepanek Fastmail PO Box 234 Collins St. West Melbourne VIC 8007 Australia Email: rsto@fastmailteam.com Stepanek Expires 25 August 2025 [Page 8]