1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00

Changes to address Daurnimator message of 7 Sep

This commit is contained in:
Steve Kille 2016-09-07 07:48:13 +01:00
parent 0dac51f925
commit 2a5599dafa

View File

@ -533,7 +533,7 @@
</join>
</iq>
]]></example>
<p>The channel must process the join atomically. The channel responds with an IQ-result. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to. This response will also include other nodes requested where subscription failed for the same reason. A user may subsequently request subscription to nodes in a channel to which the user was not initially subscribed. </p>
<p>The channel responds with an IQ-result. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to. This response will also include other nodes requested where subscription failed for the same reason. A user may subsequently request subscription to nodes in a channel to which the user was not initially subscribed. </p>
<example caption="Channel Successfully Processes Join"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
@ -1145,7 +1145,12 @@
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID. </p>
<section2 topic="Choosing Which Invite to Send" anchor="mix-muc-invite-choice">
<p>
Where a client supports MUC and MIX and has determined that for a channel that the server also supports a MUC room, the client has a choice as to which type of invite to send. A simple approach might be to always send a MUC invite, and anticipate that a MIX capable client will be able to perform the same calculation and join the MIX channel based on a MUC invite. Another simple approach would be to try the MIX invite and only fall back to MUC invite if the MIX invite failes.
</p>
<p>QUESTION: Input on this is invited. What can/should be recommended.</p>
</section2>
</section1>