moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-13 21:05:09 -05:00
Code Issues Releases Wiki Activity

Add requirement for UUID v4 for id attributes

Browse Source
This commit is contained in:
Thilo Molitor 2023-01-05 06:43:51 +01:00
parent 2b6db98c3c
commit b9f1686d38
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
xep-0353.xml
View File

@ -27,6 +27,14 @@
&fippo; &fippo;
&stpeter; &stpeter;
&tmolitor; &tmolitor;
<revision>
<version>0.5.0</version>
<date>2022-01-05</date>
<initials>tm</initials>
<remark>
Recommend usage of UUID v4 for id attributes.
</remark>
</revision>
<revision> <revision>
<version>0.4.0</version> <version>0.4.0</version>
<date>2021-11-27</date> <date>2021-11-27</date>
@ -98,7 +106,7 @@
<section1 topic='Use Cases' anchor='usecases'> <section1 topic='Use Cases' anchor='usecases'>
<p>All &MESSAGE; stanzas exchanged by this protocol MUST be of type="chat" and contain &xep0334; &lt;store/&gt; hints.</p> <p>All &MESSAGE; stanzas exchanged by this protocol MUST be of type="chat" and contain &xep0334; &lt;store/&gt; hints.</p>
<section2 topic='Indicating Intent to Start a Session' anchor='intent'> <section2 topic='Indicating Intent to Start a Session' anchor='intent'>
<p>In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a &lt;propose/&gt; element qualified by the 'urn:xmpp:jingle-message:1' namespace. The &lt;propose/&gt; element MUST possess an 'id' attribute that will be used for the session invitation of &xep0166; and MUST contain one &lt;description/&gt; element for each media type associated with the intended session.</p> <p>In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a &lt;propose/&gt; element qualified by the 'urn:xmpp:jingle-message:1' namespace. The &lt;propose/&gt; 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 &lt;propose/&gt; element MUST contain one &lt;description/&gt; element for each media type associated with the intended session.</p>
<example caption="Initiator Sends Intent Message"><![CDATA[ <example caption="Initiator Sends Intent Message"><![CDATA[
<message from='romeo@montague.example/orchard' <message from='romeo@montague.example/orchard'
to='juliet@capulet.example' to='juliet@capulet.example'
@ -395,6 +403,7 @@
Without &xep0280; implementations would need to send copies of outgoing messages to their own bare jid, to inform their own devices about an event (like it was done with the &lt;accept/&gt; message in the old urn:xmpp:jingle:jingle-message:0 specification).</p> Without &xep0280; implementations would need to send copies of outgoing messages to their own bare jid, to inform their own devices about an event (like it was done with the &lt;accept/&gt; message in the old urn:xmpp:jingle:jingle-message:0 specification).</p>
<p>In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a &lt;propose/&gt; message because they could receive another message for the same Jingle session id later in the catchup process invalidating the &lt;propose/&gt; received before. Showing the "incoming call" UI as soon as receiving an &lt;accept/&gt; might comprise bad UX.</p> <p>In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a &lt;propose/&gt; message because they could receive another message for the same Jingle session id later in the catchup process invalidating the &lt;propose/&gt; received before. Showing the "incoming call" UI as soon as receiving an &lt;accept/&gt; might comprise bad UX.</p>
<p>In the rare case of missing &lt;finish/&gt; 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.</p> <p>In the rare case of missing &lt;finish/&gt; 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.</p>
<p>All 'id' attributes MUST be globally unique to make sure they do not collide, and therefore it is RECOMMENDED to use UUIDv4.</p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>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.</p> <p>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.</p>