JSContact Version 2.0: A JSON Representation of Contact Data

Introduction JSContact defines the Card object uid property, a mandatory property that contains a unique identifier for the entity represented by that contact card. For the same purpose, the vCard contact format defines the UID property, an optional property of a vCard instance. Throughout the rest of this document, the term uid (all lowercase) denotes the JSContact uid property, and the term UID (all uppercase) denotes the vCard UID property. The uid property being defined as mandatory in JSContact has shown to be applicable for some use cases but 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 JSON Meta Application Protocol (JMAP) for Contacts requires the uid property of a JSContact Card to be set. In contrast, protocols such as Registration Data Access Protocol (RDAP) have no use for the uid property, either because they use different identifiers or 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. Also, 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, requiring unique identifiers is especially problematic: The Card uid property is mandatory, and accordingly, requires implementations to generate some unique identifier for it during conversion, but it 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 property or relatedTo property of another Card object, introducing invalid relations between contact cards.

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 .

JSContact Version 2.0 This document redefines the uid property of a Card object to become optional. Other than that, the property definition is left unchanged. This change requires the major version of JSContact to change, so this document defines the JSContact version to become "2.0". For further information about versioning JSContact data, see . Implementations MUST create JSContact data that complies with the definitions of version "2.0" (or some later registered version) and MUST set the version property of the JSContact Card object to that version. They MUST NOT reject a Card object without the uid property as invalid unless specified differently in another document or unless the Card version property has value "1.0". As any valid version "1.0" JSContact Card is also 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 is able to consistently generate the exact same unique identifier for a JSContact Card representing the same entity and no protocol-specific concerns prevail, it is recommended to set the uid property. This document does not redefine the vCard UID property.

Redefined uid Property This document redefines the type signature of the uid property, originally defined in . OLD:

uid: String (mandatory).

NEW:

uid: String (optional).

The remaining property definition is left unchanged, with the following additional paragraph:

A Card without an uid property cannot be referred to as a 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 as follows: 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 a value for the uid property (). When converting a vCard without a UID property to 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. describes why this is problematic. Consequently, implementations SHOULD NOT convert to version "1.0" Card objects.

Other Changes This document also registers the JSCOMPS parameter in the IANA "vCard Parameters" registry. The parameter was defined in but mistakenly not registered at IANA.

IANA Considerations

Update to the JSContact Version Registry IANA has updated the "JSContact Version" registry, originally created in , by adding the following record: JSContact Version Registry

Major Version	Highest Minor Version	Reference
2	0	RFC 9982

Update to the JSContact Properties Registry IANA has updated the "JSContact Properties" registry, originally created in : In the "Reference/Description" column of the uid property, a reference to of this document has been added.

Update to the vCard Parameters Registry IANA has updated the "vCard Parameters" registry within the "vCard Elements" registry group by adding the following entry: vCard Parameters Registry

Namespace	Parameter	Reference
	JSCOMPS

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