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

Corrections and Clarifications

Browse Source
This commit is contained in:
Steve Kille 2017-07-18 11:15:32 +01:00
parent 7c3eb51290
commit a9f0b658f7
1 changed files with 14 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
xep-0369.xml
View File

@ -38,7 +38,7 @@
&stpeter;
<revision>
<version>0.9.3</version>
<date>2017-06-20</date>
<date>2017-07-18</date>
<initials>sek</initials>
<remark><p>
Remove Legacy MIX Namespace;
@ -701,7 +701,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section1 topic="Error Handling" anchor="error-handling">
<p>
The MIX specification is built on layered services that have defined errors. This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed. A message sender MUST be prepared to handle any valid error from the layer services. When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender. For example a message receiver might use the "not authorized" IQ error in response to a MIX disco that is not authorized. Errors for the following layer services need to be handled for MIX:
The MIX specification is built on layered services that have defined errors. This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed. A message sender MUST be prepared to handle any valid error from the layer services. When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender. For example a receiving entity might use the "not authorized" error in response to a disco query that is not authorized. Errors for the following layer services need to be handled for MIX:
</p>
<ol>
<li>IQ. All of the IQ errors of &rfc6120; MUST be supported.</li>
@ -1374,7 +1374,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example>
<p>
The channel will return the nick that is to be used, noting that this MAY be different to the requested nick. MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;.
On successful nick assignment, the channel will return the nick that is to be used, noting that this MAY be different to the requested nick. MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;. The channel MAY return a conflict error or other appropriate error.
</p>
<example caption="Channel informs user of Nick"><![CDATA[
@ -1444,7 +1444,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</register>
</iq>
]]></example>
<p>If the requested nick is already taken, the MIX service returns a &lt;conflict/&gt; error:</p>
<p>If the requested nick is already taken and the MIX service does not assign an alternate nick, the MIX service MUST return a &lt;conflict/&gt; error:</p>
<example caption="Nick is Taken">
<![CDATA[<iq type='error'
to='mix.shakespeare.example'
@ -1455,7 +1455,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</error>
</iq>
]]></example>
<p>If the register request does not contain a &lt;nick/&gt; element, then the MIX service assigns one. It is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.
<p>If the register request does not contain a &lt;nick/&gt; element, then the MIX service MUST assign one. It is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.
</p>
@ -1717,13 +1717,20 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Retracting a Message" anchor="usecase-retract">
<p>
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by adding to the message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:1' namespace as shown in the following example.
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by adding to the message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:1' namespace. The &lt;retract&gt; element MUST include an &lt;id&gt; attribute that holds the id of the original message. A message and it's retraction shown in the following example.
</p>
<example caption="User Retracts a Message"><![CDATA[
<message from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='abcde'>
<body> A Message I did not mean to send </body>
</message>
<message from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='92vax143g'>
<retract id='28482-98726-73623' xmlns='urn:xmpp:mix:1'/>
<retract id='abcde' xmlns='urn:xmpp:mix:1'/>
</message>
]]></example>
<p>