From b9f1686d382db71c2e8254a32972db1e743b93d9 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Thu, 5 Jan 2023 06:43:51 +0100 Subject: [PATCH] Add requirement for UUID v4 for id attributes --- xep-0353.xml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/xep-0353.xml b/xep-0353.xml index a9fac98c..59f9f886 100644 --- a/xep-0353.xml +++ b/xep-0353.xml @@ -27,6 +27,14 @@ &fippo; &stpeter; &tmolitor; + + 0.5.0 + 2022-01-05 + tm + + Recommend usage of UUID v4 for id attributes. + + 0.4.0 2021-11-27 @@ -98,7 +106,7 @@

All &MESSAGE; stanzas exchanged by this protocol MUST be of type="chat" and contain &xep0334; <store/> hints.

-

In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:1' namespace. The <propose/> element MUST possess an 'id' attribute that will be used for the session invitation of &xep0166; and MUST contain one <description/> element for each media type associated with the intended session.

+

In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:1' namespace. The <propose/> element MUST possess an 'id' attribute being a globally unique identifier. It therefore is RECOMMENDED to use UUIDv4. This id will also be used for the session invitation of &xep0166; later on. The <propose/> element MUST contain one <description/> element for each media type associated with the intended session.

In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a <propose/> message because they could receive another message for the same Jingle session id later in the catchup process invalidating the <propose/> received before. Showing the "incoming call" UI as soon as receiving an <accept/> might comprise bad UX.

In the rare case of missing <finish/> elements from both initiator and responder, sessions SHOULD be considered terminated after an appropriate timeframe (for example 24 hours) and indicated so in the UI.

+

All 'id' attributes MUST be globally unique to make sure they do not collide, and therefore it is RECOMMENDED to use UUIDv4.

Because exchanging messages with other entities is effectively is a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of accept messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending accept messages does not occur by default.