rfc9982v1.txt		rfc9982.txt
	skipping to change at line 81 ¶		skipping to change at line 81 ¶
	by that contact card. For the same purpose, the vCard [RFC6350]		by that contact card. For the same purpose, the vCard [RFC6350]
	contact format defines the UID property, an optional property of a		contact format defines the UID property, an optional property of a
	vCard instance. Throughout the rest of this document, the term uid		vCard instance. Throughout the rest of this document, the term uid
	(all lowercase) denotes the JSContact uid property, and the term UID		(all lowercase) denotes the JSContact uid property, and the term UID
	(all uppercase) denotes the vCard UID property.		(all uppercase) denotes the vCard UID property.
	The uid property being defined as mandatory in JSContact has shown to		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		be applicable for some use cases but turned out to be an issue in
	other contexts.		other contexts.
	For example, the CardDAV protocol [RFC6352] requires the UID property		1. A stated goal of JSContact is to be compatible with the semantics
	of a vCard object [RFC6350] to be set. Accordingly, an internet		of the vCard data format (Section 1 of [RFC9553]). But [RFC6350]
	server that implements both CardDAV and JSON Meta Application		defines the UID property of a vCard to be optional, and
	Protocol (JMAP) for Contacts [RFC9610] requires the uid property of a		consequently, the semantics of JSContact and vCard differ for
	JSContact Card to be set. In contrast, protocols such as		such a crucial common element.
	Registration Data Access Protocol (RDAP) [RFC9083] 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		2. The CardDAV protocol [RFC6352] requires the UID property of a
	the semantics of the vCard data format (Section 1 of [RFC9553]). But		vCard object [RFC6350] to be set. Accordingly, an internet
	[RFC6350] defines the UID property of a vCard to be optional, and		server that in addition to CardDAV also implements JSON Meta
	consequently, the semantics of JSContact and vCard differ for such a		Application Protocol (JMAP) for Contacts [RFC9610] also expects
	crucial common element.		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 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.
	In case of vCards without a UID property (Section 6.7.6 of [RFC6350])		3. Converting vCards having no UID property to JSContact is
	being converted to JSContact, requiring unique identifiers is		especially problematic: Section 2.1.1 of [RFC9555] requires
	especially problematic: The Card uid property is mandatory, and		implementations in this case to generate a unique identifier
	accordingly, Section 2.1.1 of [RFC9555] requires implementations to		during conversion but does not require it to be the same across
	generate some unique identifier for it during conversion, but it does		implementations or even one implementation converting the same
	not guarantee it to be the same across implementations or even one		Card multiple times. A recipient being unaware that the uid
	implementation converting the same Card multiple times. A recipient		property value of such a Card object is ephemeral might refer to
	being unaware that the uid property value of such a Card object is		it in the members property or relatedTo property of another Card
	ephemeral might refer to it in the members property or relatedTo		object, introducing invalid relations between contact cards.
	property of another Card object, introducing invalid relations
	between contact cards.
	2. Notational Conventions		2. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The ABNF definitions in this document use the notations of [RFC5234].		The ABNF definitions in this document use the notations of [RFC5234].
	skipping to change at line 141 ¶		skipping to change at line 139 ¶
	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 unless		as invalid unless specified differently in another document or unless
	the Card version property has value "1.0". As any valid version		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		"1.0" JSContact Card is also valid according to version "2.0", there
	is no need to migrate existing JSContact data.		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.		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].		originally defined in Section 2.1.9 of [RFC9553].
	OLD:		OLD:
	| *uid: String (mandatory).*		| *uid: String (mandatory).*
	skipping to change at line 182 ¶		skipping to change at line 175 ¶
	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 as follows:		conversion rule is as follows:
	Implementations that convert a vCard without a UID property		Implementations that convert a vCard without a UID property
	(Section 6.7.6 of [RFC6350]) to a Card of version "2.0" or higher		(Section 6.7.6 of [RFC6350]) to a Card of version "2.0" or higher
	MUST NOT generate a unique identifier as a value for the uid property		MUST NOT generate a unique identifier as a value for the uid property
	(Section 2.1.9 of [RFC9553]).		(Section 2.1.9 of [RFC9553]).
	When converting a vCard without a 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		How to generate unique identifiers is implementation-specific.
	implementation SHOULD generate the same value when generating the		Implementations SHOULD generate the same value when generating the
	same Card multiple times. Section 1 describes why this is		same Card multiple times, but as Section 1 describes, this still
	problematic. Consequently, implementations SHOULD NOT convert to		cannot prevent interoperability issues. Consequently,
	version "1.0" Card objects.		implementations SHOULD NOT convert to version "1.0" Card objects.
	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
End of changes. 5 change blocks.
	36 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48.