JSContact: Optional Unique Identifiers

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 when, and only when, they appear in all capitals, as shown here. The ABNF definitions in this document use the notations of . ABNF rules not defined in this document are defined in either (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT) or .

Introduction 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 requires the UID property of a vCard object to be set. Accordingly, an internet server that implements both CardDAV and JMAP for Contacts requires the "uid" property of a JSContact Card to be set. In contrast, protocols such as RDAP 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 (). But 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. In case of vCards without a UID property being converted to JSContact, this semantic difference is especially problematic: the Card "uid" property is mandatory and accordingly requires implementations to generate some unique identifier for it during conversion, but does not guarantee it to be the same across implementations or even one implementation converting the same Card multiple times. A recipient being unaware that the "uid" property value of such a Card object is ephemeral might refer to it in the "members" or "relatedTo" properties of another Card object, introducing invalid relations between contact cards. 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".

Redefined "uid" Property This document redefines the type signature of the "uid" property, originally defined in . The new type signature is:

uid: String (optional).

The remaining property definition is left unchanged, with the following additional paragraph: A Card without a uid property can not be referred to as group member in the "members" property, or put in relation to another Card object in the "relatedTo" property.

Redefined Conversion Rule for the "uid" Property This document redefines how to convert the Card "uid" property from vCard, originally defined in . The new conversion rule is: Implementations that convert a vCard without a UID property to a Card of version "2.0" or higher MUST NOT generate a unique identifier as value for the "uid" property. When converting a vCard without UID property to obsoleted JSContact version "1.0", implementations MUST generate a value for the "uid" property. Generating unique identifiers is implementation-specific. An implementation SHOULD generate the same value when generating the same Card multiple times, but MAY generate different values for each conversion. describes why this is problematic. Consequently, implementations SHOULD NOT convert to version "1.0" Card objects.

IANA Considerations

Update to the JSContact Version Registry IANA will update the "JSContact Version" registry, originally created in . It will add the following record: JSContact Version Registry

Major Version	Highest Minor Version	Reference
2	0	This document

Update to the JSContact Properties Registry IANA will update the "JSContact Properties" registry, originally created in . It will add a reference to of this document to the "Reference/Description" column of the "uid" property.

Security Considerations This document does not provide new security considerations. The security considerations of apply.