moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Merge branch 'feature/xep-0422'

This commit is contained in:
Jonas Schäfer 2019-12-30 15:05:56 +01:00
parent 735b17dcc7 3131fe5835
commit 5978bdf3a6
1 changed files with 44 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
xep-0422.xml
View File

@ -29,6 +29,13 @@
<surname>Smith</surname>
<email>kevin.smith@isode.com</email>
</author>
&dcridland;
<revision>
<version>0.2.0</version>
<date>2019-12-30</date>
<initials>ks/dwd</initials>
<remark>Preparation for extending MAM</remark>
</revision>
<revision>
<version>0.1.2</version>
<date>2019-12-16</date>
@ -56,7 +63,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>
There are many situations in which a message contains a payload that contains content that adds additional information to the context of a previous message. Examples of this might be a user sending a rection (e.g. a thumbs-up emoji) to another user's message, or a server adding information on a link previously posted to a chat room, a user updating/editing the content of a message they've previously sent. This specification provides a generic wrapper to fasten such new payloads to the message to which they apply.
There are many situations in which a message contains a payload that adds additional information to the context of a previous message. Examples of this might be a user sending a reaction (e.g. a thumbs-up emoji) to another user's message, or a server adding information on a link previously posted to a chat room, a user updating/editing the content of a message they've previously sent. This specification provides a generic wrapper to fasten such new payloads to the message to which they apply.
</p>
</section1>
<section1 topic='Discovering support' anchor='disco'>
@ -89,10 +96,11 @@
<section2 topic="Wrapped Payloads" anchor="wrapped-payloads">
<p>In order to mark that a payload applies to a previous message, a message is sent containing an "apply-to" element in the namespace "urn:xmpp:fasten:0", with attribute "id" that contains the &xep0359; origin-id of the stanza to which it applies, the children of which element are those that apply to the previous message (these are "wrapped payloads" because they are wrapped inside the &lt;apply-to&gt; element). The id of this apply-to-containing message is unimportant, and the type SHOULD be "normal" (KS: I don't care about this, it just seemed easier to spell it out).</p>
<p>If "user2@chatservice.example" wanted to send their approval (using a fictional 'i-like-this' element) for a message previously sent to chat room "chatroom@chatservice.example" with origin-id "origin-id-1", they would do the following.</p>
<p>An &lt;apply-to&gt; may contain several fastenings, but they must all be of the same type (the same qualified name)</p>
<example caption="User2 sends fictional approval"><![CDATA[
<message id="2" from="user2@chatservice.example" to "chatroom@chatservice.example">
<apply-to xmlns="urn:xmpp:fasten:0" id="origin-id-1">
<i-like-this xmlns='urn:example:lik'/>
<i-like-this xmlns='urn:example:like'/>
</apply-to>
</message>
]]></example>
@ -103,24 +111,48 @@
<example caption="User2 applies"><![CDATA[
<message id="4" from="user2@chatservice.example" to="chatroom@chatservice.example">
<apply-to xmlns="urn:xmpp:fasten:0" id="origin-id-2">
<external name='body'/>
<external name='custom' element-namespace='urn:example:custom'/>
<edit xmlns='urn:example.edit'/>
<external name='body'/>
</apply-to>
<body>Hi there</body>
<custom xmlns='urn:example:custom'>New data</custom>
</message>
]]></example>
<p>Note that the first child of the &lt;apply-to&gt; should be the fastening type, and the &lt;external&gt; should follow. If a receiving entity finds unknown namespaced elements inside an &lt;apply-to&gt; with qualified name different to the fastening type, they should be ignored (this allows us to introduce new fastening children in the future, similar to &lt;external&gt;, and maintain backwards compatibility).</p>
</section2>
<section2 topic="Replacing a previous fastening" anchor="replace">
<p>When an entity wishes to replace a fastening they have previously applied it does this by including an attribute 'replace' with value 'true' on the &lt;apply-to&gt; element. The child payload of the &lt;apply-to&gt; element then logically replaces a fastening previously applied by the sending entity with the same name and namespace.</p>
<section2 topic="Replacing fastenings" anchor="replace">
<p>A fastening of a given type (qualified name) can be replaced by sending a new fastening of the same qualified name - as with the original fastening there may be several fastenings of this type (qualified name), but all fastenings must be of the same type. The child payloads of the &lt;apply-to&gt; element then logically replace all fastenings previously applied by the sending entity with the same qualified name (name and namespace).</p>
<p>For example, if user2 wished to update the fastening from the first example they would send:</p>
<example caption="User2 applies"><![CDATA[
<message id="6" from="user2@chatservice.example" to="chatroom@chatservice.example">
<apply-to xmlns="urn:xmpp:fasten:0" id="origin-id-1" replace='true'>
<i-like-this xmlns='urn:example:lik'>Very much</i-like-this>
<apply-to xmlns="urn:xmpp:fasten:0" id="origin-id-1">
<i-like-this xmlns='urn:example:like'>Very much</i-like-this>
</apply-to>
</message>
]]></example>
</section2>
<section2 topic="Removing fastenings" anchor="remove">
<p>Fastenings of a given type (qualified name) can be removed by sending a new (empty) fastening of the same qualified name only (no other attributes and no children) and setting an attribute 'clear' with value 'true' on the &lt;apply-to;&gt; element. This logically replaces all the previous fastenings from this sender of this qualified name with an empty list of fastenings.</p>
<p>For example, if user2 wished to remove the fastenings from the first example they would send:</p>
<example caption="User2 applies"><![CDATA[
<message id="6" from="user2@chatservice.example" to="chatroom@chatservice.example">
<apply-to xmlns="urn:xmpp:fasten:0" id="origin-id-1" clear="true">
<i-like-this xmlns='urn:example:like'/>
</apply-to>
</message>
]]></example>
</section2>
<section2 topic="Interaction with stanza encryption" anchor="encryption">
<p>Where the contents of a fastening are sensitive and must be encrypted (e.g. if a message editing spec. uses fastening, the contents of the edit are sensitive), it is suggested that the plaintext contains an &lt;apply-to&gt; with no content other than the id and an attribute of "shell" whose value is "true", to indicate that the apply-to is a shell with no content. This allows a server to still collate the fastened stanzas, while not allowing it to read the content. The encrypted content MUST then include the full &lt;apply-to&gt; element, which a client MUST use post-decryption and ignore the shell element.</p>
<example caption="Encrypted fastening"><![CDATA[
<message id="9" from="user2@chatservice.example" to="chatroom@chatservice.example">
<apply-to xmlns="urn:xmpp:fasten:0" id="origin-id-1" shell="true"/>
<!--This is encrypted-->
<apply-to xmlns="urn:xmpp:fasten:0" id="origin-id-1">
<i-like-this xmlns='urn:example:like'/>
</apply-to>
<!--end encryption-->
</message>
]]></example>
</section2>
</section1>
@ -129,6 +161,7 @@
<p>A message must only contain a single "apply-to" element (i.e. a message cannot be fastened to multiple other messages).</p>
<p>Fastenings are not to be chained - an &lt;apply-to&gt; element MUST reply to the original message to which it applies, not to an earlier fastening-containing-message (the 'id' attribute of an &lt;apply-to&gt; element must not be that of a stanza that itself contains an &lt;apply-to&gt;). For example, if this spec is used in the future to wrap multiple subsquent message edits for the same source message, each &lt;apply-to&gt; would contain the original stanza's id, not the id of any subsequent fastening stanza.</p>
<p>Some payloads should not be allowed to be fastened to a particular message by all users - e.g. if used to wrap message edits, it would be expected that only the original author be allowed to edit their message. It's the responsibility of specifications for protocols to be fastened to destribe such "who is allowed to do this?" applicability rules.</p>
<p>Multiple fastenings of the same type may be present in a single attach-to element, but fastening types may not be mixed in this way.</p>
<p>TODO: (future XEP) special handling by the archive to allow grouping and querying of things fastened to a message (this is going to involve following the externals and potentially wrapping them inside the apply-to when fetching from the archive).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
@ -142,4 +175,7 @@
</ul>
</section2>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The authors would like to thank Marvin Wissfeld, Florian Schmaus, Philipp Hörist, Jonas Schäfer, Ralph Meijer and others who've replied on-list for their feedback.</p>
</section1>
</xep>