From 26cac6d2ce7f30b566565770b4ae753207a096c5 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 4 May 2018 10:01:44 +0100 Subject: [PATCH] Editorial --- xep-0369.xml | 140 ++++++++++++++++++++++++++++----------------------- 1 file changed, 77 insertions(+), 63 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 29a0ecea..529a9a68 100644 --- a/xep-0369.xml +++ b/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.

- 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.

- 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.

]]>

- 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.

@@ -2271,23 +2271,25 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - - + + + urn:xmpp:mix:1 - - Information Node Modification - - Witches Coven - - - - + + Information Node Modification + + Witches Coven + + + + + @@ -2300,21 +2302,25 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='set'> - - - urn:xmpp:mix:1 - - - Witches Coven - - - A location not far from the blasted heath where + + + + + urn:xmpp:mix:1 + + + Witches Coven + + + A location not far from the blasted heath where the three witches meet - - - greymalkin@shakespeare.example - - + + + greymalkin@shakespeare.example + + + + @@ -2325,7 +2331,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - + + + @@ -2350,15 +2358,17 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - - - urn:xmpp:mix:1 - - Configuration Node Modification - - + + + + urn:xmpp:mix:1 + + Configuration Node Modification + + + @@ -2371,24 +2381,28 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='set'> - - - urn:xmpp:mix:1 - - - hecate@shakespeare.example - greymalkin@shakespeare.example - - - allowed - - - jid-mandatory-visible - - - true - - + + + + + urn:xmpp:mix:1 + + + hecate@shakespeare.example + greymalkin@shakespeare.example + + + allowed + + + jid-mandatory-visible + + + true + + + + @@ -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.

- 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.