mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-22 01:02:17 -05:00
Editorial
This commit is contained in:
Steve Kille
parent
95500aeef9
commit
26cac6d2ce
24
xep-0369.xml
24
xep-0369.xml
@ -1130,7 +1130,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
At the same time the participant MUST be added to the JID Map node, to map from proxy JID to real JID. For a JID Maybe Visible channel, the participant MUST be added to the JID Maybe Visible Map node. The value in this node MUST reflect the user's visibility preference for the channel and MUST be updated to reflect any changes to this preference.
|
||||
</p>
|
||||
<p>
|
||||
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/$gt; child element of <iq/> element. The <update-subscription/$gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/$gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.
|
||||
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/> child element of <iq/> element. The <update-subscription/> element is qualified by the 'urn:xmpp:mix:1' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/> element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.
|
||||
</p>
|
||||
<example caption="User Modifies Subscription Request"><![CDATA[
|
||||
<iq type='set'
|
||||
@ -2199,8 +2199,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
A common use case for an ad hoc channel is where two users are engaged in a 1:1 chat and wish to broaden the discussion. Prior to bringing more users into a channel, using standard invitation process, there is a need to create and populate a channel. The first step is for one of the two users to create an ad hoc channel, as described in the previous section. The other user will then be invited, and can switch to the new channel.
|
||||
</p>
|
||||
<p>
|
||||
It can also be useful to share some or all of the messages from the 1:1 discussion into the new channel. The mechanism to do this is to forward messages to be shared in the MUC using &xep0297;. A body SHOULD NOT be used in the outer message.
|
||||
Sharing history is optional. If history is shared, it MUST be done by the user creating the channel before the other user is invited. Any other use of forwarded messages MUST be treated as a member of the MUC forwarding a message to the channel and MUST NOT be treated as history sharing.
|
||||
It can also be useful to share some or all of the messages from the 1:1 discussion into the new channel. The mechanism to do this is to forward messages to be shared to the channel using &xep0297;. A body SHOULD NOT be used in the outer message.
|
||||
Sharing history is optional. If history is shared, it MUST be done by the user creating the channel before the other user is invited. Any other use of forwarded messages MUST be treated as a channel participant forwarding a message to the channel and MUST NOT be treated as history sharing.
|
||||
</p>
|
||||
<example caption="Forwarding a message to create History" ><![CDATA[
|
||||
<message from='hag66@shakespeare.example/UUID-a1j/7533'
|
||||
@ -2220,7 +2220,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</message>
|
||||
]]></example>
|
||||
<p>
|
||||
There are a number of security considerations with use of MUC history. There may be sensitive information in the 1:1 MUC history, and the user sharing this history should ensure that none of this is sensitive, prior to sharing in this way. The user creating the MUC has potential to inject history messages which were not part of the history. It is recommended that the second user joining the MUC to validate that the messages match the history and to take appropriate action if they do not.
|
||||
There are a number of security considerations with sharing 1:1 history in a channel. There may be sensitive information in the 1:1 history, and the user sharing this history should ensure that none of this is sensitive, prior to sharing in this way. The user creating the channel has potential to inject history messages which were not part of the history. It is recommended that the second user joining the channel to validate that the messages match the history and to take appropriate action if they do not.
|
||||
</p>
|
||||
</section3>
|
||||
|
||||
@ -2271,6 +2271,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
type='result'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/'>
|
||||
<items node='urn:xmpp:mix:nodes:info'>
|
||||
<item>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:1</value>
|
||||
@ -2288,6 +2289,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
label='Channel Administrative Contact'
|
||||
var='Contact'/>
|
||||
</x>
|
||||
</item>
|
||||
</items>
|
||||
</pubsub>
|
||||
</iq>
|
||||
@ -2300,6 +2302,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
type='set'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='urn:xmpp:mix:nodes:info'>
|
||||
<items>
|
||||
<item>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:1</value>
|
||||
@ -2315,6 +2319,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<value>greymalkin@shakespeare.example</value>
|
||||
</field>
|
||||
</x>
|
||||
</item>
|
||||
</items>
|
||||
</publish>
|
||||
</pubsub>
|
||||
</iq>
|
||||
@ -2325,7 +2331,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
type='result'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='urn:xmpp:mix:nodes:info'>
|
||||
<items>
|
||||
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:1'/>
|
||||
</items>
|
||||
</publish>
|
||||
</pubsub>
|
||||
</iq>
|
||||
@ -2350,6 +2358,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
type='result'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<items xmlns='urn:xmpp:mix:1' node='urn:xmpp:mix:nodes:config'>
|
||||
<item>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:1</value>
|
||||
@ -2359,6 +2368,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
label='Channel Administrator'
|
||||
var='Administrator'/>
|
||||
</x>
|
||||
</item>
|
||||
</items>
|
||||
</pubsub>
|
||||
</iq>
|
||||
@ -2371,6 +2381,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
type='set'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='urn:xmpp:mix:nodes:config'>
|
||||
<items>
|
||||
<item>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:1</value>
|
||||
@ -2389,6 +2401,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<value>true</value>
|
||||
</field>
|
||||
</x>
|
||||
<item/>
|
||||
<items/>
|
||||
</publish>
|
||||
</pubsub>
|
||||
</iq>
|
||||
@ -2504,7 +2518,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
Messages from a MIX channel will usually go to the participant's server. The only exception to this is where the MIX channel is responding directly to messages from the client. Messages and presence distributed but a MIX channel will always be sent to the participant's server and addressed to the user's bare JID. The participant's server will simply send on the messages from the channel to each of the user's online clients which advertise MIX capability. If there are no such clients activated, the message is dropped.
|
||||
</p>
|
||||
<p>
|
||||
Messages sent to the participant's sever will always be addressed to the user's bare JID. The participant’s server will modify the recipient to the full JID of each client to which the message is forwarded. The participant's server MUST NOT make any other modifications to each message. The following example, repeated from earlier, shows a message distributed by a MIX channel and directed to the participant’s server with the participant's bare JID.
|
||||
Messages sent to the participant's sever will always be addressed to the user's bare JID. The participant’s server will modify the recipient to the full JID of each client to which the message is forwarded. The following example, repeated from earlier, shows a message distributed by a MIX channel and directed to the participant’s server with the participant's bare JID.
|
||||
</p>
|
||||
<example caption="Channel Reflects Message to Participants"><![CDATA[
|
||||
<message from='coven@mix.shakespeare.example'
|
||||
|
||||
Loading…
Reference in New Issue
Block a user