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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
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,
<https://www.rfc-editor.org/info/rfc6352>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON
Representation of Contact Data", RFC 9553,
DOI 10.17487/RFC9553, May 2024,
<https://www.rfc-editor.org/info/rfc9553>.
[RFC9610] Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP)
for Contacts", RFC 9610, DOI 10.17487/RFC9610, December
2024, <https://www.rfc-editor.org/info/rfc9610>.
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]