| RFC draft-stepanek-jscontact-uid-00 | JSContact: Optional UIDs | June 2025 |
| Stepanek | Expires 6 December 2025 | [Page] |
This document redefines the mandatory "uid" property of a Card object to become optional. This is both for using JSContact in other protocols than CardDAV and JMAP for Contacts, as well as to align the semantics of the vCard UID property with JSContact. This is a breaking change, this document introduces version "2.0" to replace the current JSContact version "1.0".¶
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 6 December 2025.¶
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 either [RFC5234] (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT) or [RFC6350].¶
[RFC9553] defines the "uid" property of a Card object, a mandatory property which contains an unique identifier for the entity represented by that contact card. This property being mandatory has shown to be applicable for some use cases, but has turned out to be an issue in other contexts.¶
For example, the CardDAV protocol [RFC6352] requires the UID property of a vCard object [RFC6350] to be set. Accordingly, an internet server that implements both CardDAV and JMAP for Contacts [RFC9610] requires the "uid" property of a JSContact Card to be set. In contrast, protocols such as RDAP [RFC9083] have no use for the "uid" property, either because they use different identifiers, or prefer to not include any unique identifier in the contact data at all. As another example, one of the stated goals of JSContact is to be compatible with the semantics of the vCard data format (Section 1 of [RFC9553]). But [RFC6350] defines the UID property of a vCard to be optional, and consequently the semantics of JSContact and vCard differ for such a crucial common element.¶
This document redefines the "uid" property of a Card object to become optional. Other than that, the property definition is left unchanged. This is a breaking change: all current version "1.0" Cards are still valid according to the new definition, but new Card objects that omit the "uid" property are invalid according to the definitions of version "1.0". As a consequence, this document updates the current JSContact version to become "2.0".¶
This document redefines the type signature of the "uid" property, originally defined in Section 2.1.9 of [RFC9553]. The new type signature is:¶
The remaining property definition is left unchanged.¶
This document redefines how to convert the Card "uid" property from vCard, originally defined in Section 2.1.1 of [RFC9555]. The new conversion rule is:¶
Implementations that convert a vCard without a UID property [RFC6350] (Section 6.7.6) to a Card of version "2.0" or higher MAY generate a unique identifier as value for the "uid" property [RFC9553] (Section 2.1.9), they MUST do so for a Card of version "1.0". This value SHOULD be the same when converting the same vCard multiple times, but how to achieve this is implementation-specific.¶
IANA will update the "JSContact Version" registry, originally created in Section 3.4 of [RFC9553]. It will add the following record:¶
| Major Version | Highest Minor Version | Reference |
|---|---|---|
| 2 | 0 | This document |
IANA will update the "JSContact Properties" registry, originally created in Section 3.5 of [RFC9553]. It will add a reference to Section 3 of this document to the "Reference/Description" column of the "uid" property.¶
This document does not provide new security considerations. The security considerations of Section 4 of [RFC9553] apply.¶