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

Merge branch 'feature/xep-0369'

Browse Source
This commit is contained in:
Jonas Wielicki 2018-01-02 13:07:27 +01:00
commit b92191feba
1 changed files with 107 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

183
xep-0369.xml
View File

@ -37,6 +37,25 @@
&skille;
&stpeter;
<revision>
<version>0.9.4</version>
<date>2018-02-02</date>
<initials>sek</initials>
<remark><p>
Various Clarifications from Georg Lukas review:
Role Membership reword,
Participant's Node Joining clarification,
Joining Channel Clarification,
Coming online clarification,
Going offline JID error,
Allow servers to limit retract time frame,
Clarify that private messages must not be groupchat,
Creating Channel Clarification,
Address security concerns on Converting a 1:1 Conversation to a Channel,
Remove requirement for all user clients to support MIX,
Change Retract to use MAM-ID;
Ensure use of .example throughout (follow RFC conventions);
</p></remark>
</revision> <revision>
<version>0.9.3</version>
<date>2017-07-18</date>
<initials>sek</initials>
@ -353,7 +372,7 @@
<li>Online clients MAY register presence, which is then shared with participants who have subscribed to presence.</li>
<li>MIX decouples addressing of channel participants from their nicknames, so that nickname changes do not affect addressing.</li>
<li>Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource (also anonymized) are then constructed, allowing visibility into the number of online resources participating in a channel.</li>
<li> Although some protocol is shared with MUC, MUC clients are not interoperable with a MIX service. This means that where a user chooses to use MIX, all of the users clients need to support MIX.</li>
<li> Although some protocol is shared with MUC, MUC clients are not interoperable with a MIX service. </li>
<li>MIX requires the server to which the MIX client connects to provide functionality to support MIX. This functionality is defined in this specification and referenced as "MIX Participant's Server Behaviour".</li>
<li>MIX domains MUST NOT be used to host end user JIDs. </li>
</ol>
@ -488,7 +507,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<tr><td>Anyone</td><td>Any user, including users in the banned node.</td></tr>
</table>
<p>
There MUST always be at least one Owner. Administrators, Participants, and Allowed MAY NOT have any members. Rights are defined in a strictly hierarchical manner following the order of this table, so that for example Owners will always have rights that Administrators have.
There MUST always be at least one Owner for a Channel. Administrators, Participants, and Allowed are optional and do not need to be set. Rights are defined in a strictly hierarchical manner following the order of this table, so that for example Owners will always have rights that Administrators have.
</p>
</section3>
@ -509,7 +528,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:1' namespace. The nick associated with the user is mandatory and is stored in a &lt;nick/&gt; child element of the &lt;participant/&gt; element. The nick for each channel participant MUST be different to the nick of other participants.
</p>
<p>
When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
When a user joins a channel, the user's bare proxy JID is added to the participants node by the MIX service. When a user leaves a channel, the user's bare proxy JID is removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
</p>
<p>
Users MAY subscribe to and read information this node, when permitted by the channel. Standard PubSub access will allow a full list of participants and associated nicks to be determined. By subscribing to the node, a user will be informed of changes to the Participants Node.
@ -602,7 +621,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
the three witches meet</value>
</field>
<field var='Contact'>
<value>greymalkin@shakespeare.lit</value>
<value>greymalkin@shakespeare.example</value>
</field>
<field var='JID Visibility'>
<value>jid-visible</value>
@ -619,8 +638,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
<example caption="Allowed Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:allowed'>
<item id='shakespeare.lit'/>
<item id='alice@wonderland.lit'/>
<item id='shakespeare.example'/>
<item id='alice@wonderland.example'/>
</items>
]]></example>
</section3>
@ -630,8 +649,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
<example caption="Banned Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:banned'>
<item id='lear@shakespeare.lit'/>
<item id='macbeth@shakespeare.lit'/>
<item id='lear@shakespeare.example'/>
<item id='macbeth@shakespeare.example'/>
</items>
]]></example>
</section3>
@ -675,10 +694,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<value>urn:xmpp:mix:1</value>
</field>
<field var='Owner'>
<value>hecate@shakespeare.lit</value>
<value>hecate@shakespeare.example</value>
</field>
<field var='Owner'>
<value>greymalkin@shakespeare.lit</value>
<value>greymalkin@shakespeare.example</value>
</field>
<field var='Messages Node Subscription'>
<value>allowed</value>
@ -775,13 +794,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<example caption='Client Queries for Channels on MIX Service'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
to='mix.shakespeare.lit'
to='mix.shakespeare.example'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
]]></example>
<example caption='MIX Service Returns Disco Items Result'><![CDATA[
<iq from='mix.shakespeare.lit'
<iq from='mix.shakespeare.example'
id='kl2fax27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
@ -798,14 +817,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<example caption='Entity Queries for Information about a Specific Channel'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='ik3vs715'
to='coven@mix.shakespeare.lit'
to='coven@mix.shakespeare.example'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info' node='mix'/>
</iq>
]]></example>
<p>If the querying user is allowed to subscribe, the channel MUST return its identity and the features it supports. Note that a MIX channel MUST support MAM and so the response will always include both MIX and MAM support. All disco queries on a MIX channel and results returned MUST include the attribute node='mix'. The reason for this is to facilitate MIX channels and &xep0045; MUC rooms sharing the same JID. This extra parameter will enable a server to return appropriate information.</p>
<example caption='Channel Returns Disco Info Result'><![CDATA[
<iq from='coven@mix.shakespeare.lit'
<iq from='coven@mix.shakespeare.example'
id='ik3vs715'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
@ -825,13 +844,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<example caption='Entity Queries for Nodes at a Channel'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
to='coven@mix.shakespeare.lit'
to='coven@mix.shakespeare.example'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'/ node='mix'>
</iq>
]]></example>
<example caption='Channel Returns Disco Items Result'><![CDATA[
<iq from='coven@mix.shakespeare.lit'
<iq from='coven@mix.shakespeare.example'
id='kl2fax27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
@ -853,7 +872,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<example caption='Client Requests Channel Information'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
to='coven@mix.shakespeare.lit'
to='coven@mix.shakespeare.example'
type='get'>
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:info'/>
@ -861,7 +880,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</iq>
]]></example>
<example caption='MIX Service Returns Channel Information'><![CDATA[
<iq from='coven@mix.shakespeare.lit'
<iq from='coven@mix.shakespeare.example'
id='kl2fax27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
@ -881,7 +900,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
the three witches meet</value>
</field>
<field var='Contact'>
<value>greymalkin@shakespeare.lit</value>
<value>greymalkin@shakespeare.example</value>
</field>
</x>
</item>
@ -896,7 +915,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<example caption='User&apos;s Client Requests Participant List'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
to='coven@mix.shakespeare.lit'
to='coven@mix.shakespeare.example'
type='get'>
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:participants'/>
@ -904,7 +923,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</iq>
]]></example>
<example caption='MIX Service Returns Participant List'><![CDATA[
<iq from='coven@mix.shakespeare.lit'
<iq from='coven@mix.shakespeare.example'
id='kl2fax27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
@ -934,17 +953,17 @@ This approach enables flexible support of multiple clients for a MIX channel pa
Where a client supports MIX, it MUST advertise this capability in response to a Disco request. This will enable other entities to determine if a client supports MIX, and in particular it facilitates the client's server to determine client support. This can be optimized by use of CAPS. The following example shows a Disco request to and response from a client that supports both MIX and MUC.
</p>
<example caption='Disco Query for MIX support'><![CDATA[
<iq from='juliet@capulet.lit/UUID-e3r/9264'
<iq from='juliet@capulet.example/UUID-e3r/9264'
id='d1rt87mr4w'
to='romeo@montague.lit/UUID-m2t/3945'
to='romeo@montague.example/UUID-m2t/3945'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq from='romeo@montague.lit/UUID-m2t/3945'
<iq from='romeo@montague.example/UUID-m2t/3945'
id='d1rt87mr4w'
to='juliet@capulet.lit/UUID-e3r/9264'
to='juliet@capulet.example/UUID-e3r/9264'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='http://jabber.org/protocol/caps'/>
@ -961,7 +980,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Common User Use Cases' anchor='usecases-user'>
<section3 topic='Joining a Channel' anchor='usecase-user-join'>
<p>A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. The &lt;join/&gt; is a child element of &lt;iq/&gt; element. The &lt;join/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the &lt;join/&gt; element. The requested nodes are encoded as &lt;subscribe/&gt; child elements of the &lt;join/&gt; element.
<p>A user joins a channel by sending a MIX "join" command from one of the user's clients. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. The &lt;join/&gt; is a child element of &lt;iq/&gt; element. The &lt;join/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the &lt;join/&gt; element. The requested nodes are encoded as &lt;subscribe/&gt; child elements of the &lt;join/&gt; element.
The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
</p>
@ -969,7 +988,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>
The user's server needs to make roster changes as part of the join functionality. Because of this, the join and leave operations need to operate indirectly.
For this reason the initial join request is sent to the local server with the MIX channel specified as an attribute to the join.
For this reason the initial join request is sent to the local server with the MIX channel specified as an attribute to the join. The join is sent from a client identified by a full JID to the user's bare JID.
</p>
<example caption="Client sends request to Local Server to Join a Channel"><![CDATA[
@ -1019,7 +1038,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example>
<p>
The user's server will then send the join response back to the client that made the join request. The only change is that the incoming message is addressed to bare JID and the outgoing message is addressed to client's full JID. Prior to sending this response, the user's server will make roster modifications as set out in the next section.
The user's server will then make roster modifications as set out in the next section.
After making these changes, the user's server will send the join response back to the client that made the join request, identified by the full JID. This is illustrated below:
</p>
<example caption="User's Server sends response to Client"><![CDATA[
@ -1035,6 +1055,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</join>
</iq>
]]></example>
<p>
This response informs the client that initiated the join request that the request has been completed. Note that the roster changes described in the next section will lead to roster update information being sent to all of the user's online clients, so that all of the user's clients will be updated with the new MIX channel information.
</p>
<p>
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 at least one node is requested and 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 error response will also include other nodes requested where subscription failed for the same reason. </p>
@ -1510,8 +1534,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Client Coming Online and Obtaining Presence from the Local Server" anchor="usecase-obtaining-presence">
<p>
The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to the server of each user subscribing to this presence node. The user's local server will then pass this presence information on to all online clients. This ensures that an online client is kept updated with presence.
When a client goes offline, it will cease getting presence updates. Presence updates will continue to flow to the user's local server, and so the local server is able maintain up to date presence state for the channel.
The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to the server of each user subscribing to this presence node. The user's local server will then pass this presence information on to all online clients. This ensures that an online client is kept updated with presence.
When a client goes offline, it will cease getting presence updates. Presence updates will continue to flow to the user's local server, and so the local server is able maintain up to date presence state for the channel. The user's server MAY cache this presence information to optimize performance or MAY discard it.
</p>
<p>
When the client comes online, it will activate use of the MIX. The user's server will then send full presence status to the client using standard presence messages. This will enable the client to update presence information for the channel. Note that this does not need any interaction with the channel.
@ -1542,7 +1566,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<example caption='Client looks up Real JID from Proxy JID'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
to='coven@mix.shakespeare.lit'
to='coven@mix.shakespeare.example'
type='get'>
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:jidmap'>
@ -1551,7 +1575,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</pubsub>
</iq>
<iq from='coven@mix.shakespeare.lit'
<iq from='coven@mix.shakespeare.example'
id='kl2fax27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
@ -1576,7 +1600,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<example caption='Client looks up Real JID from Proxy JID in MAM Archive'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
to='coven@mix.shakespeare.lit'
to='coven@mix.shakespeare.example'
type='set'>
<query xlns='urn:xmpp:mam:2'
queryid='f28'
@ -1611,7 +1635,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</result>
</message>
<iq from='coven@mix.shakespeare.lit'
<iq from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
type='result'>
@ -1644,7 +1668,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'/>
]]></example>
<p>The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID. The MIX channel will notify subscribers to the presence node of the user going offline by sending a presence stanza to the full proxy JID of each client.</p>
<p>The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID. The MIX channel will notify subscribers to the presence node of the user going offline by sending a presence stanza to the full JID of each client. The presence stanza will reference the full proxy JID of the client that is going offline, as shown in the following example:</p>
<example caption="Channel Distributes Notification of Client going Offline">
<![CDATA[<presence from='12345#coven@mix.shakespeare.example/678'
to='hecate@shakespeare.example'
@ -1726,7 +1751,7 @@ 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. 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.
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:1' namespace. A retract messages MUST NOT have a body. The &lt;retract&gt; element MUST include an &lt;id&gt; attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and it's retraction shown in the following example.
</p>
<example caption="User Retracts a Message"><![CDATA[
@ -1739,29 +1764,29 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<message from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='92vax143g'>
<retract id='abcde' xmlns='urn:xmpp:mix:1'/>
<retract id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' xmlns='urn:xmpp:mix:1'/>
</message>
]]></example>
<p>
The MIX channel will allow a user to retract a message sent by the user if the 'Allow User Message Retraction' option is configured. The MIX channel will allow an administrative user to retract any message if the user is in the group specified by the 'Administrator Message Retraction Rights' option.
</p>
<p>
If the retraction message is accepted, it will be distributed to channel participants. This will allow retraction to happen in the MAM archive of each channel participant and to reflect the retraction in client GUI. A client receiving a retraction message SHOULD ensure that the retracted message is no longer displayed to the end user.
If the retraction message is accepted, it MUST be distributed to channel participants. This will allow retraction to happen in the MAM archive of each channel participant and to reflect the retraction in client GUI. A client receiving a retraction message SHOULD ensure that the retracted message is no longer displayed to the end user.
</p>
<p>
Two approaches to message retraction can be used. In the first approach, the retracted message is simply removed. This is appropriate where retraction is provided as a user service and the user has rights to remove messages sent from the record.
</p>
<p>
The second approach is to leave a tombstone, which if taken MUST be done in the following manner. This is appropriate where it is desired to leave a record of the message that was redacted.
The second approach is to leave a tombstone, which if taken MUST be done in the following manner. It is recommended to use a tombstone, as simply deleting the message may cause confusion with MAM queries. Use of a tombstone is appropriate where it is desired to leave a record of the message that was redacted.
With this approach, the original message &lt;body&gt; is removed and replaced with a tombstone using the &lt;retracted&gt; element qualified by the 'urn:xmpp:mix:1' namespace that shows the JID of user performing the retraction and the time of the retraction.
</p>
<example caption="Retracted message tombstone in a MAM result"><![CDATA[
<message id='aeb213' to='juliet@capulet.lit/UUID-e3r/9264'>
<message id='aeb213' to='juliet@capulet.example/UUID-e3r/9264'>
<result xmlns='urn:xmpp:mam:1' queryid='f27' id='28482-98726-73623'>
<forwarded xmlns='urn:xmpp:forward:0'>
<delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
<message xmlns='jabber:client' from="hag66@shakespeare.example"
to="macbeth@shakespeare.lit">
to="macbeth@shakespeare.example">
<retracted xmlns='urn:xmpp:mix:1' by='hag66@shakespeare.example'
time='2010-07-10T23:08:25Z'/>
</message>
@ -1793,25 +1818,25 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an &lt;invite/&gt; child element of an &lt;iq/&gt; element. The &lt;invite/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. &lt;invite/&gt; contains an &lt;invitation/&gt; child element, which contain &lt;inviter/&gt;, &lt;invitee/&gt;, &lt;channel/&gt; and &lt;token/&gt; child elements.
</p>
<example caption='Inviter Requests and Receives Invitation'><![CDATA[
<iq from='hag66@shakespeare.lit/UUID-h5z/0253'
<iq from='hag66@shakespeare.example/UUID-h5z/0253'
id='kl2fax27'
to='coven@mix.shakespeare.lit'
to='coven@mix.shakespeare.example'
type='get'>
<invite xmlns='urn:xmpp:mix:1'>
<invitee>cat@shakespeare.lit</invitee>
<invitee>cat@shakespeare.example</invitee>
</invite>
</iq>
<iq from='coven@mix.shakespeare.lit'
<iq from='coven@mix.shakespeare.example'
id='kl2fax27'
to='hag66@shakespeare.lit/UUID-h5z/0253'
to='hag66@shakespeare.example/UUID-h5z/0253'
type='result'>
<invite xmlns='urn:xmpp:mix:1'>
<invitation>
<inviter>hag66@shakespeare.lit</inviter>
<invitee>cat@shakespeare.lit</invitee>
<channel>coven@mix.shakespeare.lit</channel>
<inviter>hag66@shakespeare.example</inviter>
<invitee>cat@shakespeare.example</invitee>
<channel>coven@mix.shakespeare.example</channel>
<token>ABCDEF</token>
</invitation>
<invite/>
@ -1821,14 +1846,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The inviter can now send the invitee a message containing the invitation within the &lt;message/&gt; element, as shown in the following example.
</p>
<example caption='Inviter sends Invitation to Invitee'><![CDATA[
<message from='hag66@shakespeare.lit/UUID-h5z/0253'
<message from='hag66@shakespeare.example/UUID-h5z/0253'
id='f5pp2toz'
to='cat@shakespeare.lit'>
to='cat@shakespeare.example'>
<body>Would you like to join the coven?<body>
<invitation xmlns='urn:xmpp:mix:1'>
<inviter>hag66@shakespeare.lit</inviter>
<invitee>cat@shakespeare.lit</invitee>
<channel>coven@mix.shakespeare.lit</channel>
<inviter>hag66@shakespeare.example</inviter>
<invitee>cat@shakespeare.example</invitee>
<channel>coven@mix.shakespeare.example</channel>
<token>ABCDEF</token>
</invitation>
</iq>
@ -1842,9 +1867,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<join xmlns='urn:xmpp:mix:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<invitation>
<inviter>hag66@shakespeare.lit</inviter>
<invitee>cat@shakespeare.lit</invitee>
<channel>coven@mix.shakespeare.lit</channel>
<inviter>hag66@shakespeare.example</inviter>
<invitee>cat@shakespeare.example</invitee>
<channel>coven@mix.shakespeare.example</channel>
<token>ABCDEF</token>
</invitation>
</join>
@ -1859,16 +1884,16 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<li>'Acknowledged': The invitation is acknowledged, without information on action taken or planned.</li>
</ul>
<example caption='Invitee sends Acknowledgement to Inviter'><![CDATA[
<message from='cat@shakespeare.lit/UUID-l1w/8813'
<message from='cat@shakespeare.example/UUID-l1w/8813'
id='b6p9llze'
to='hag66@shakespeare.lit/UUID-h5z/0253'>
to='hag66@shakespeare.example/UUID-h5z/0253'>
<body>No Thanks - too busy chasing mice....<body>
<invitation-ack xmlns='urn:xmpp:mix:1'>
<value>Declined</value>
<invitation>
<inviter>hag66@shakespeare.lit</inviter>
<invitee>cat@shakespeare.lit</invitee>
<channel>coven@mix.shakespeare.lit</channel>
<inviter>hag66@shakespeare.example</inviter>
<invitee>cat@shakespeare.example</invitee>
<channel>coven@mix.shakespeare.example</channel>
<token>ABCDEF</token>
</invitation>
</invitation-ack>
@ -1880,7 +1905,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic='Sending Private Messages' anchor='usecase-user-private-messages'>
<p>
Private Messages are used to provide communication with another channel participant through the MIX channel, without the initiating user knowing the real JID of the channel participant. A channel MAY support use of Private Messages. Private messages are standard XMPP messages. A message goes through a number of stages with different addressing. This is set out in the following table.
Private Messages are used to provide communication with another channel participant through the MIX channel, without the initiating user knowing the real JID of the channel participant. A channel MAY support use of Private Messages. Private messages are standard XMPP messages and MUST NOT be groupchat. A message goes through a number of stages with different addressing. This is set out in the following table.
</p>
<table caption="Setting From and To when sending Private Messages">
<tr><th>Message</th><th>From</th><th>To</th></tr>
@ -1911,7 +1936,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<example caption="Channel passes on vCard request to the User&apos;s Server" ><![CDATA[
<iq from='123456#coven@mix.shakespeare.example/6789'
id='lx09df27'
to='peter@shakespeare.lit'
to='peter@shakespeare.example'
type='get'>
<vCard xmlns='vcard-temp'/>
</iq>
@ -1920,7 +1945,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The user's server, on behalf of the user, MAY send a response or reject with an error. The user's server will send the vCard back to the channel.
</p>
<example caption="User's Server sends vCard Response via MIX channel" ><![CDATA[
<iq from='peter@shakespeare.lit'
<iq from='peter@shakespeare.example'
id='lx09df27'
to='123456#coven@mix.shakespeare.example/6789'
type='result'>
@ -2048,7 +2073,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section3>
<section3 topic='Creating a Channel' anchor='usecase-admin-create'>
<p>
A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a &lt;create/&gt; child element of &lt;iq/&gt; element. The &lt;create/&gt; is qualified by the 'urn:xmpp:mix:1' namespace. The &lt;create/&gt; element MUST have a 'channel' attribute to specify the channel name.
A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a &lt;create/&gt; child element of &lt;iq/&gt; element. The &lt;create/&gt; is qualified by the 'urn:xmpp:mix:1' namespace. The &lt;create/&gt; element MUST have a 'channel' attribute to specify the channel name. This attribute specifies the value that will be used in the LHS of the JID for the MIX channel.
</p>
<example caption="Creating a Channel with Default Parameters" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-a1j/7533'
@ -2079,8 +2104,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<value>urn:xmpp:mix:1</value>
</field>
<field var='Owner'>
<value>hecate@shakespeare.lit</value>
<value>greymalkin@shakespeare.lit</value>
<value>hecate@shakespeare.example</value>
<value>greymalkin@shakespeare.example</value>
</field>
<field var='Messages Node Subscription'>
<value>allowed</value>
@ -2132,7 +2157,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</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.
This will generally be done by the user creating the channel before the other user is invited, but MAY be sent by either the user creating the channel or the 1:1 chat partner at any time subsequently.
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.
</p>
<example caption="Forwarding a message to create History" ><![CDATA[
<message from='hag66@shakespeare.example/UUID-a1j/7533'
@ -2151,6 +2176,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</forwarded>
</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.
</p>
</section3>
<section3 topic='Destroying a Channel' anchor='usecase-admin-destroy'>
@ -2241,7 +2269,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
the three witches meet</value>
</field>
<field var='Contact'>
<value>greymalkin@shakespeare.lit</value>
<value>greymalkin@shakespeare.example</value>
</field>
</x>
</publish>
@ -2305,8 +2333,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<value>urn:xmpp:mix:1</value>
</field>
<field var='Owner'>
<value>hecate@shakespeare.lit</value>
<value>greymalkin@shakespeare.lit</value>
<value>hecate@shakespeare.example</value>
<value>greymalkin@shakespeare.example</value>
</field>
<field var='Messages Node Subscription'>
<value>allowed</value>
@ -2355,8 +2383,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:allowed'>
<item id='shakespeare.lit'/>
<item id='alice@wonderland.lit'/>
<item id='shakespeare.example'/>
<item id='alice@wonderland.example'/>
</items>
</pubsub>
</iq>
@ -2371,7 +2399,7 @@ 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:allowed'>
<item id='marlow.lit'/>
<item id='marlow.example'/>
</items>
</pubsub>
</iq>
@ -2393,7 +2421,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<retract node='urn:xmpp:mix:nodes:banned'>
<item id='lear@shakespeare.lit'/>
<item id='lear@shakespeare.example'/>
</items>
</pubsub>
</iq>
@ -2737,6 +2765,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>
MIX provides flexible access control options, which MUST be used in a manner appropriate to the security requirements of MIX users and services.
</p>
<p>
When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.
</p>
</section1>