JSContact: Optional Unique Identifiers
draft-ietf-calext-jscontact-uid-00

calext                                                       R. Stepanek
Internet-Draft                                                  Fastmail
Updates: 9553, 9555 (if approved)                           23 June 2025
Intended status: Standards Track                                        
Expires: 25 December 2025

                 JSContact: Optional Unique Identifiers
                   draft-ietf-calext-jscontact-uid-00

Abstract

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

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 December 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Stepanek                Expires 25 December 2025                [Page 1]
RFC draft-ietf-calext-jsJSContact:dOptional UIDs               June 2025

   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  . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Redefined "uid" Property  . . . . . . . . . . . . . . . . . .   3
   4.  Redefined Conversion Rule for the "uid" Property  . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
     5.1.  Update to the JSContact Version Registry  . . . . . . . .   3
     5.2.  Update to the JSContact Properties Registry . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

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

   [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

Stepanek                Expires 25 December 2025                [Page 2]
RFC draft-ietf-calext-jsJSContact:dOptional UIDs               June 2025

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

3.  Redefined "uid" Property

   This document redefines the type signature of the "uid" property,
   originally defined in Section 2.1.9 of [RFC9553].  The new type
   signature is:

   *uid: String (optional).*

   The remaining property definition is left unchanged.

4.  Redefined Conversion Rule for the "uid" Property

   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.

5.  IANA Considerations

5.1.  Update to the JSContact Version Registry

   IANA will update the "JSContact Version" registry, originally created
   in Section 3.4 of [RFC9553].  It will add the following record:

Stepanek                Expires 25 December 2025                [Page 3]
RFC draft-ietf-calext-jsJSContact:dOptional UIDs               June 2025

         +===============+=======================+===============+
         | Major Version | Highest Minor Version | Reference     |
         +===============+=======================+===============+
         | 2             | 0                     | This document |
         +---------------+-----------------------+---------------+

                    Table 1: JSContact Version Registry

5.2.  Update to the JSContact Properties Registry

   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.

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

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

Stepanek                Expires 25 December 2025                [Page 4]
RFC draft-ietf-calext-jsJSContact:dOptional UIDs               June 2025

   [RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 9083, DOI 10.17487/RFC9083, June 2021,
              <https://www.rfc-editor.org/info/rfc9083>.

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

   [RFC9555]  Loffredo, M. and R. Stepanek, "JSContact: Converting from
              and to vCard", RFC 9555, DOI 10.17487/RFC9555, May 2024,
              <https://www.rfc-editor.org/info/rfc9555>.

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

Author's Address

   Robert Stepanek
   Fastmail
   PO Box 234
   Collins St. West
   Melbourne VIC 8007
   Australia
   Email: rsto@fastmailteam.com

Stepanek                Expires 25 December 2025                [Page 5]