rfc9982.original   rfc9982.txt 
calext R. Stepanek Internet Engineering Task Force (IETF) R. Stepanek
Internet-Draft Fastmail Request for Comments: 9982 Fastmail
Updates: 9555 (if approved) 19 November 2025 Updates: 9555 May 2026
Intended status: Standards Track Category: Standards Track
Expires: 23 May 2026 ISSN: 2070-1721
JSContact Version 2.0: A JSON Representation of Contact Data JSContact Version 2.0: A JSON Representation of Contact Data
draft-ietf-calext-jscontact-uid-07
Abstract Abstract
This document defines version "2.0" of JSContact. It defines the uid This document defines version "2.0" of JSContact. It defines the uid
property of a Card object to be optional, rather than mandatory as property of a Card object to be optional, rather than mandatory, as
defined in previous version "1.0". All other definitions of defined previously in version "1.0". All other definitions of
JSContact version "1.0" remain as defined in RFC 9553. This document JSContact version "1.0" remain as defined in RFC 9553. This document
updates RFC 9555 by redefining how to convert the now optional uid updates RFC 9555 by redefining how to convert the now optional uid
property from and to vCard. It also registers the vCard JSCOMPS property from and to vCard. It also registers the vCard JSCOMPS
parameter at IANA, which was defined but not registered in RFC 9555. parameter at IANA, which was defined but not registered in RFC 9555.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 23 May 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9982.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
RFC draft-ietf-calext-jscoJSContact-Version 2.0 November 2025
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions
3. JSContact Version 2.0 . . . . . . . . . . . . . . . . . . . . 3 3. JSContact Version 2.0
4. Redefined uid Property . . . . . . . . . . . . . . . . . . . 4 4. Redefined uid Property
5. Redefined Conversion Rule for the uid Property . . . . . . . 4 5. Redefined Conversion Rule for the uid Property
6. Other Changes . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Other Changes
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations
7.1. Update to the JSContact Version Registry . . . . . . . . 5 7.1. Update to the JSContact Version Registry
7.2. Update to the JSContact Properties Registry . . . . . . . 5 7.2. Update to the JSContact Properties Registry
7.3. Update to the vCard Parameters Registry . . . . . . . . . 5 7.3. Update to the vCard Parameters Registry
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 6 9.2. Informative References
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address
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 1. Introduction
JSContact [RFC9553] defines the Card object uid property, a mandatory JSContact [RFC9553] defines the Card object uid property, a mandatory
property which contains a unique identifier for the entity property that contains a unique identifier for the entity represented
represented by that contact card. For the same purpose, the vCard by that contact card. For the same purpose, the vCard [RFC6350]
[RFC6350] contact format defines the UID property, an optional contact format defines the UID property, an optional property of a
property of a vCard instance. Throughout the rest of this document, vCard instance. Throughout the rest of this document, the term uid
the term uid (all lowercase) denotes the JSContact uid property, the (all lowercase) denotes the JSContact uid property, and the term UID
(all uppercase) denotes the vCard UID property.
RFC draft-ietf-calext-jscoJSContact-Version 2.0 November 2025
term UID (all uppercase) denotes the vCard UID property.
That the uid property was defined to be mandatory in JSContact has The uid property being defined as mandatory in JSContact has shown to
shown to be applicable for some use cases, but turned out to be an be applicable for some use cases but turned out to be an issue in
issue in other contexts: other contexts.
For example, the CardDAV protocol [RFC6352] requires the UID property For example, the CardDAV protocol [RFC6352] requires the UID property
of a vCard object [RFC6350] to be set. Accordingly, an internet of a vCard object [RFC6350] to be set. Accordingly, an internet
server that implements both CardDAV and JMAP for Contacts [RFC9610] server that implements both CardDAV and JSON Meta Application
requires the uid property of a JSContact Card to be set. In Protocol (JMAP) for Contacts [RFC9610] requires the uid property of a
contrast, protocols such as RDAP [RFC9083] have no use for the uid JSContact Card to be set. In contrast, protocols such as
property, either because they use different identifiers, or they Registration Data Access Protocol (RDAP) [RFC9083] have no use for
prefer to not include any unique identifier in the contact data at the uid property, either because they use different identifiers or
all. JSContact should not require them to generate unique they prefer to not include any unique identifier in the contact data
at all. JSContact should not require them to generate unique
identifiers that are irrelevant to their use case. identifiers that are irrelevant to their use case.
Also, one of the stated goals of JSContact is to be compatible with Also, one of the stated goals of JSContact is to be compatible with
the semantics of the vCard data format (Section 1 of [RFC9553]). But the semantics of the vCard data format (Section 1 of [RFC9553]). But
[RFC6350] defines the UID property of a vCard to be optional, and [RFC6350] defines the UID property of a vCard to be optional, and
consequently the semantics of JSContact and vCard differ for such a consequently, the semantics of JSContact and vCard differ for such a
crucial common element. crucial common element.
In case of vCards without a UID property [RFC6350] (Section 6.7.6) In case of vCards without a UID property (Section 6.7.6 of [RFC6350])
being converted to JSContact, requiring unique identifiers is being converted to JSContact, requiring unique identifiers is
especially problematic: the Card uid property is mandatory and especially problematic: The Card uid property is mandatory, and
accordingly Section 2.1.1 of [RFC9555] requires implementations to accordingly, Section 2.1.1 of [RFC9555] requires implementations to
generate some unique identifier for it during conversion, but it does generate some unique identifier for it during conversion, but it does
not guarantee it to be the same across implementations or even one not guarantee it to be the same across implementations or even one
implementation converting the same Card multiple times. A recipient implementation converting the same Card multiple times. A recipient
being unaware that the uid property value of such a Card object is being unaware that the uid property value of such a Card object is
ephemeral might refer to it in the members property or relatedTo ephemeral might refer to it in the members property or relatedTo
property of another Card object, introducing invalid relations property of another Card object, introducing invalid relations
between contact cards. between contact cards.
2. 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].
3. JSContact Version 2.0 3. JSContact Version 2.0
This document redefines the uid property of a Card object to become This document redefines the uid property of a Card object to become
optional. Other than that, the property definition is left optional. Other than that, the property definition is left
unchanged. This change requires the major version of JSContact to unchanged. This change requires the major version of JSContact to
change, so this document defines the JSContact version to become change, so this document defines the JSContact version to become
"2.0". For further information about versioning JSContact data, see "2.0". For further information about versioning JSContact data, see
Section 1.9 of [RFC9553]. Section 1.9 of [RFC9553].
Implementations MUST create JSContact data that complies with the Implementations MUST create JSContact data that complies with the
definitions of version "2.0" (or some later registered version) and definitions of version "2.0" (or some later registered version) and
MUST set the version property of the JSContact Card object to that MUST set the version property of the JSContact Card object to that
version. They MUST NOT reject a Card object without the uid property version. They MUST NOT reject a Card object without the uid property
as invalid unless specified differently in another document, or as invalid unless specified differently in another document or unless
the Card version property has value "1.0". As any valid version
RFC draft-ietf-calext-jscoJSContact-Version 2.0 November 2025 "1.0" JSContact Card is also valid according to version "2.0", there
is no need to migrate existing JSContact data.
unless the Card version property has value "1.0". As any valid
version "1.0" JSContact Card also is valid according to version
"2.0", there is no need to migrate existing JSContact data.
Setting the uid property is use-case specific. If an implementation Setting the uid property is use case specific. If an implementation
is able to consistently generate the exact same unique identifier for is able to consistently generate the exact same unique identifier for
a JSContact Card representing the same entity and no protocol- a JSContact Card representing the same entity and no protocol-
specific concerns prevail, it is recommended to set the uid property. specific concerns prevail, it is recommended to set the uid property.
This document does not redefine the vCard UID property. This document does not redefine the vCard UID property.
4. Redefined uid Property 4. Redefined uid Property
This document redefines the type signature of the uid property, This document redefines the type signature of the uid property,
originally defined in Section 2.1.9 of [RFC9553]. The new type originally defined in Section 2.1.9 of [RFC9553].
signature is:
*uid: String (optional).* OLD:
| *uid: String (mandatory).*
NEW:
| *uid: String (optional).*
The remaining property definition is left unchanged, with the The remaining property definition is left unchanged, with the
following additional paragraph: following additional paragraph:
| A Card without an uid property can not be referred to as group | A Card without an uid property cannot be referred to as a group
| member in the members property [RFC9553] (Section 2.1.6), or put | member in the members property (Section 2.1.6 of [RFC9553]) or put
| in relation to another Card object in the relatedTo property | in relation to another Card object in the relatedTo property
| [RFC9553] (Section 2.1.8). | (Section 2.1.8 of [RFC9553]).
5. Redefined Conversion Rule for the uid Property 5. Redefined Conversion Rule for the uid Property
This document redefines how to convert the Card uid property from This document redefines how to convert the Card uid property from
vCard, originally defined in Section 2.1.1 of [RFC9555]. The new vCard, originally defined in Section 2.1.1 of [RFC9555]. The new
conversion rule is: conversion rule is as follows:
Implementations that convert a vCard without a UID property [RFC6350] Implementations that convert a vCard without a UID property
(Section 6.7.6) to a Card of version "2.0" or higher MUST NOT (Section 6.7.6 of [RFC6350]) to a Card of version "2.0" or higher
generate a unique identifier as value for the uid property [RFC9553] MUST NOT generate a unique identifier as a value for the uid property
(Section 2.1.9). (Section 2.1.9 of [RFC9553]).
When converting a vCard without UID property to JSContact version When converting a vCard without a UID property to JSContact version
"1.0", implementations MUST generate a value for the uid property. "1.0", implementations MUST generate a value for the uid property.
Generating unique identifiers is implementation-specific. An Generating unique identifiers is implementation specific. An
implementation SHOULD generate the same value when generating the implementation SHOULD generate the same value when generating the
same Card multiple times. Section 2 describes why this is same Card multiple times. Section 1 describes why this is
problematic. Consequently, implementations SHOULD NOT convert to problematic. Consequently, implementations SHOULD NOT convert to
version "1.0" Card objects. version "1.0" Card objects.
RFC draft-ietf-calext-jscoJSContact-Version 2.0 November 2025
6. Other Changes 6. Other Changes
This document also registers the JSCOMPS parameter in the IANA "vCard This document also registers the JSCOMPS parameter in the IANA "vCard
Parameters" registry. The parameter was defined in Section 3.3.1 of Parameters" registry. The parameter was defined in Section 3.3.1 of
[RFC9555] but mistakenly not registered at IANA. [RFC9555] but mistakenly not registered at IANA.
7. IANA Considerations 7. IANA Considerations
7.1. Update to the JSContact Version Registry 7.1. Update to the JSContact Version Registry
IANA will update the "JSContact Version" registry, originally created IANA has updated the "JSContact Version" registry, originally created
in Section 3.4 of [RFC9553]. It will add the following record: in Section 3.4 of [RFC9553], by adding the following record:
+===============+=======================+===============+ +===============+=======================+===========+
| Major Version | Highest Minor Version | Reference | | Major Version | Highest Minor Version | Reference |
+===============+=======================+===============+ +===============+=======================+===========+
| 2 | 0 | This document | | 2 | 0 | RFC 9982 |
+---------------+-----------------------+---------------+ +---------------+-----------------------+-----------+
Table 1: JSContact Version Registry Table 1: JSContact Version Registry
7.2. Update to the JSContact Properties Registry 7.2. Update to the JSContact Properties Registry
IANA will update the "JSContact Properties" registry, originally IANA has updated the "JSContact Properties" registry, originally
created in Section 3.5 of [RFC9553]: In the "Reference/Description" created in Section 3.5 of [RFC9553]: In the "Reference/Description"
column of the uid property, it will add a reference to Section 4 of column of the uid property, a reference to Section 4 of this document
this document. has been added.
7.3. Update to the vCard Parameters Registry 7.3. Update to the vCard Parameters Registry
IANA will update the "vCard Parameters" registry within the "vCard IANA has updated the "vCard Parameters" registry within the "vCard
Elements" registry. It will add the following entry: Elements" registry group by adding the following entry:
+===========+===========+============================+ +===========+===========+============================+
| Namespace | Parameter | Reference | | Namespace | Parameter | Reference |
+===========+===========+============================+ +===========+===========+============================+
| | JSCOMPS | Section 3.3.1 of [RFC9555] | | | JSCOMPS | Section 3.3.1 of [RFC9555] |
+-----------+-----------+----------------------------+ +-----------+-----------+----------------------------+
Table 2: vCard Parameters Registry Table 2: vCard Parameters Registry
8. Security Considerations 8. Security Considerations
This document does not provide new security considerations. The This document does not provide new security considerations. The
security considerations of Section 4 of [RFC9553] apply. security considerations of Section 4 of [RFC9553] apply.
9. References 9. References
RFC draft-ietf-calext-jscoJSContact-Version 2.0 November 2025
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
skipping to change at page 7, line 4 skipping to change at line 282
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021, RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>. <https://www.rfc-editor.org/info/rfc9083>.
[RFC9610] Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP) [RFC9610] Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP)
for Contacts", RFC 9610, DOI 10.17487/RFC9610, December for Contacts", RFC 9610, DOI 10.17487/RFC9610, December
2024, <https://www.rfc-editor.org/info/rfc9610>. 2024, <https://www.rfc-editor.org/info/rfc9610>.
Author's Address Author's Address
RFC draft-ietf-calext-jscoJSContact-Version 2.0 November 2025
Robert Stepanek Robert Stepanek
Fastmail Fastmail
PO Box 234 PO Box 234
Collins St. West Collins St. West
Melbourne VIC 8007 Melbourne VIC 8007
Australia Australia
Email: rsto@fastmailteam.com Email: rsto@fastmailteam.com
 End of changes. 37 change blocks. 
119 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.48.