mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-22 07:38:52 -05:00
Changes to address Daurnimator message of 7 Sep
This commit is contained in:
parent
0dac51f925
commit
2a5599dafa
@ -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>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user