mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
Merge commit 'refs/pull/658/head' of https://github.com/xsf/xeps
This commit is contained in:
Jonas Wielicki
commit
63724dd4b8
94
xep-0369.xml
94
xep-0369.xml
@ -36,6 +36,16 @@
|
||||
&ksmithisode;
|
||||
&skille;
|
||||
<revision>
|
||||
<version>0.11.4</version>
|
||||
<date>2018-06-05</date>
|
||||
<initials>sek</initials>
|
||||
<remark><p>
|
||||
Remove Proxy JID;
|
||||
Add Stable Participant ID;
|
||||
Remove recommendation to generate Nick as UUID;
|
||||
Add guidance on Nick display;
|
||||
</p></remark>
|
||||
</revision> <revision>
|
||||
<version>0.11.3</version>
|
||||
<date>2018-05-24</date>
|
||||
<initials>sek</initials>
|
||||
@ -402,7 +412,7 @@
|
||||
<li>XMPP clients can implement MUC and this specification in a way that provides a coherent user experience.</li>
|
||||
<li>XMPP servers can implement this specification and also provide a MUC interface in order to support clients that only implement MUC.</li>
|
||||
</ul>
|
||||
<p>This specification gives guidance on supporting both MUC and MIX representations of chatrooms.</p>
|
||||
<p>MIX gives guidance on supporting both MUC and MIX representations of chatrooms.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
@ -432,7 +442,7 @@
|
||||
|
||||
<ol>
|
||||
<li>MIX-CORE. &xep0369;. This specification, which is the central mandatory MIX specification. This sets out requirements addressed by MIX and general MIX concepts and framework. It defines joining channels and associated participant management. It defines discovery and sharing of MIX channels and information about them. It defines use of MIX to share messages with channel participants. </li>
|
||||
<li>MIX-PRESENCE. &xep0403;. This optional specification adds the ability for MIX online clients to share presence, so that this can be seen by other MIX clients.</li>
|
||||
<li>MIX-PRESENCE. &xep0403;. This optional specification adds the ability for MIX online clients to share presence, so that this can be seen by other MIX clients. It also specifies relay of IQ stanzas through a channel.</li>
|
||||
<li>MIX-PAM. &xep0405;. This specification defines how a server supporting MIX clients behaves, to support servers implementing MIX-CORE and MIX-PRESENCE.</li>
|
||||
<li>MIX-ADMIN. &xep0406;. This specifies MIX configuration and administration of MIX.</li>
|
||||
<li>MIX-ANON. &xep0404;. This specifies a mechanism to hide real JIDs from MIX clients and related privacy controls. </li>
|
||||
@ -486,9 +496,7 @@
|
||||
|
||||
<li>In MIX, a Nick belongs to the user and not to each client.</li>
|
||||
|
||||
<li>
|
||||
Presence is exchanged in MIX by use of a proxy JID, which is a stable JID on the domain of the MIX channel that identifies the user. This proxy JID is used instead of the "Nick as a Resource" mechanism in MUC. To support this, the proxy JID is a primary part of defining a MIX channel participant. Proxy JIDs are also used in MIX-ANON to provide a "JID Hidden" mechanism, to give a service similar to MUC semi-anonymous, that will prevent JID harvesting (requirement 7).
|
||||
</li>
|
||||
|
||||
|
||||
|
||||
</ol>
|
||||
@ -514,7 +522,9 @@
|
||||
<li>Presence is sent to participants using bare JID, whether or not the user has an online client. </li>
|
||||
<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>Each participant has a Stable Participant ID. This is used in some derived JIDs to provide a stable participant reference. It is used to hide JIDs in MIX-ANON.
|
||||
|
||||
</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>
|
||||
@ -531,17 +541,15 @@
|
||||
|
||||
|
||||
|
||||
<section2 topic="Proxy JIDs" anchor="proxy-jid">
|
||||
<section2 topic="Stable Participant ID" anchor="stable-id">
|
||||
|
||||
<p>
|
||||
The primary representation of a participant in a MIX channel is a proxy JID, which is an anonymized JID using the same domain as the channel and includes and encoding of the name of the channel and a random identifier. The primary reason for proxy JID is to support presence, as presence messages need to be sent from the domain of the MIX channel. MUC achieves this by using the resource to encode Nick, which does not work well. Proxy JIDs enable Nick changing and support of multiple clients (as the client resource can be shared). MIX provides a simple mechanism for clients to map the proxy JID to Nick and Real Jid, so that these are available to the MIX user. Proxy JIDs are also used to provide the "JID Hidden" mechanism, specified in MIX-ANON.
|
||||
Every channel participant is identified by a Stable Participant ID, which uniquely identifies a channel participant and never changes. The Stable Participant ID MUST NOT contain the '#', '/' or '@' characters.
|
||||
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Proxy JIDs are encoded, using the format "<generated identifier>#<channel>@<mix domain>". The generated identifier MUST NOT contain the '#', '/' or '@' characters. The Channel name MAY contain the '#' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of '123456#coven@mix.shakespeare.example'. Servers and clients MUST determine that a JID is a proxy JID from context and MUST NOT infer that a JID is a proxy JID because it contains the '#' character.
|
||||
</p>
|
||||
<p>
|
||||
The mapping of real bare JID to proxy JID is defined when a participant joins a channel. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed. This mapping must be maintained after the user leaves the channel. Proxy JID values MUST NOT be re-used. If a JID that left a channel joins the channel again, the same proxy JID MAY be used again or a different new proxy JID MAY be assigned.
|
||||
A Participant's Stable Participant ID is defined when a participant joins a channel. While a user is a participant in a Channel, the Stable Participant ID MUST NOT be changed. This mapping between Participant and Stable Participant ID MUST be maintained after the participant leaves the channel. Stable Participant ID values MUST NOT be re-used. If a participant that left a channel joins the channel again, the same Stable Participant ID MAY be used again or a different Stable Participant ID MAY be assigned.
|
||||
</p>
|
||||
|
||||
|
||||
@ -580,28 +588,31 @@
|
||||
</section3>
|
||||
|
||||
<section3 topic="Participants Node" anchor="participants-node">
|
||||
<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 <participant/> element qualified by the 'urn:xmpp:mix:core:0' namespace. The nick associated with the user is optional and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.
|
||||
<p>Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the Stable Participant ID of the participant. For example '123456' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:core:0' namespace. The nick associated with the user is optional and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.
|
||||
</p>
|
||||
<p>
|
||||
A Nick MAY be associated with a participant. The nick associated with the user is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.
|
||||
A Nick MAY be associated with a participant, which provides a user-oriented description of the participant. The nick associated with the user is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.
|
||||
</p>
|
||||
<p>
|
||||
Where a nick is provided for a user, it is generally recommended to use this nick or the JID to display the user. This enables consistent representation of participants for all participants in the channel.
|
||||
</p>
|
||||
<p>
|
||||
The real JID of the user MAY be held in the participants node. When the real JID is not present, the procedures defined in MIX-ANON must be followed.
|
||||
The user's JID is stored in a <jid/> child element of the <participant/> element.
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
When a user joins a channel, an item representing the is added to the participants node by the MIX service. When a user leaves a channel, the user's item is removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
|
||||
</p>
|
||||
<p>
|
||||
Clients will need to read the Participants node to provide useful display of presence information. For this reason, it is anticipated that Participants will be able to read the Participants node. However, for the message distribution specified in MIX-CORE, it is not necessary for clients to be able to read the Participants node.
|
||||
It may be useful for clients to read the participants list. However it is not necessary for message and presence display, as both messages and presence contain sufficient information to enable display.
|
||||
</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.
|
||||
</p>
|
||||
<p>The participants node is OPTIONAL. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used. The Participants node is a permanent node with one item per participant.</p>
|
||||
<p>The participants node is MANDATORY. The Participants node is a permanent node with one item per participant.</p>
|
||||
<example caption="Value of Participants Node"><![CDATA[
|
||||
<items node='urn:xmpp:mix:nodes:participants'>
|
||||
<item id='123456#coven@mix.shakespeare.example'>
|
||||
<item id='123456'>
|
||||
<participant xmlns='urn:xmpp:mix:core:0'>
|
||||
<nick>thirdwitch</nick>
|
||||
<jid>hag66@shakespeare.example</jid>
|
||||
@ -668,7 +679,7 @@
|
||||
<ol>
|
||||
<li>IQ. All of the IQ errors of &rfc6120; MUST be supported.</li>
|
||||
<li>Messages. If a message is received and an error situation is encountered, a message of type error MUST be sent back to the message sender. This message format is specified in &rfc6121; containing an error defined in &rfc6120;, which is the same error set as for IQs.</li>
|
||||
<li>Presence. Any responses to presence messages MUST follow the rules of &rfc6121;.</li>
|
||||
<li>Presence. If MIX-PRESENCE is supported, any responses to presence messages MUST follow the rules of &rfc6121;.</li>
|
||||
<li>PubSub. Where MIX protocol messages use PubSub protocol, the errors defined in &xep0060; MUST be used and supported.</li>
|
||||
</ol>
|
||||
</section1>
|
||||
@ -853,7 +864,8 @@
|
||||
</section2>
|
||||
<section2 topic='Determining the Participants in a Channel' anchor='find-channel-participants'>
|
||||
<p>
|
||||
Participants in the channel are determined using PubSub retrieval of the Participants Node which will give proxy JID, real JID and nick. It is anticipated that clients using a channel will often determine participants on start-up, to enable display of participants and presence. </p>
|
||||
Participants in the channel are determined using PubSub retrieval of the Participants Node which will give Stable Participant
|
||||
ID, JID and nick. Clients using a channel MAY determine participants on start-up, to enable display of participants. </p>
|
||||
<example caption='User's Client Requests Participant List'><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
id='kl2fax27'
|
||||
@ -871,13 +883,13 @@
|
||||
type='result'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:mix:nodes:participants'>
|
||||
<item id='123456#coven@mix.shakespeare.example'>
|
||||
<item id='123456'>
|
||||
<participant xmlns='urn:xmpp:mix:core:0'>
|
||||
<nick>thirdwitch</nick>
|
||||
<jid>hag66@shakespeare.example</jid>
|
||||
</participant>
|
||||
</item>
|
||||
<item id='87123#coven@mix.shakespeare.example'>
|
||||
<item id='87123'>
|
||||
<participant xmlns='urn:xmpp:mix:core:0'>
|
||||
<nick>top witch</nick>
|
||||
<jid>hecate@shakespeare.example</jid>
|
||||
@ -944,14 +956,15 @@
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>The channel responds to the user's sever with an IQ-result addressed to the user's bare JID, which will be processed as specified in MIX-PAM. 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. The JID returned in the join is the user's bare proxy JID. The following example shows the result of the above request when the request is completed in full. </p>
|
||||
<p>The channel responds to the user's sever with an IQ-result addressed to the user's bare JID, which will be processed as specified in MIX-PAM. 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. The user's Stable Participant ID is returned as an 'id' attribute in the join.
|
||||
The following example shows the result of the above request when the request is completed in full. </p>
|
||||
<example caption="Channel responds to User's Server"><![CDATA[
|
||||
<iq type='result'
|
||||
from='coven@mix.shakespeare.example'
|
||||
to='hag66@shakespeare.example'
|
||||
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
|
||||
<join xmlns='urn:xmpp:mix:core:0'
|
||||
jid='123456#coven@mix.shakespeare.example'>
|
||||
id='123456'>
|
||||
<subscribe node='urn:xmpp:mix:nodes:messages'/>
|
||||
<subscribe node='urn:xmpp:mix:nodes:presence'/>
|
||||
<subscribe node='urn:xmpp:mix:nodes:participants'/>
|
||||
@ -988,7 +1001,7 @@
|
||||
id='5A9C7398-DB13-4BFA-A091-2D466C710AAF'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='urn:xmpp:mix:nodes:participants'>
|
||||
<item id='123456#coven@mix.shakespeare.example'>
|
||||
<item id='123456'>
|
||||
<participant xmlns='urn:xmpp:mix:core:0'>
|
||||
<jid>hag66@shakespeare.example</jid>
|
||||
</participant>
|
||||
@ -997,7 +1010,7 @@
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>The user that has been added to the channel is identified by the item id of the item added to the Participants node, which is the proxy JID of the new channel participant. The <participant> element MUST include a <jid> element with the JID of the participant, unless MIX-ANON is being followed to hide participant JIDs. The <nick> element will not be included at this point, unless it is automatically generated by the channel. In the likely event that a Nick is subsequently added, an update with the <nick> element will be distributed.
|
||||
<p>The user that has been added to the channel is identified by the item id of the item added to the Participants node, which is the Stable Participant ID of the new channel participant. The <participant> element MUST include a <jid> element with the JID of the participant, unless MIX-ANON is being followed to hide participant JIDs. The <nick> element will not be included at this point, unless it is automatically generated by the channel. In the likely event that a Nick is subsequently added, an update with the <nick> element will be distributed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@ -1073,7 +1086,7 @@
|
||||
<li>The nick is registered with the user account in some way, for example as part of user provisioning with nick configured as an attribute in a directory service. For example, this could be chosen by corporate services that wish to ensure consistent nick values for a set of users and channels.</li>
|
||||
<li>The nick is registered with the MIX service, as described in <link url='#usecase-user-register'> Registering a Nick </link>.</li>
|
||||
<li>The user explicitly sets the nick, as described in this section.</li>
|
||||
<li>The MIX service generates the nick. In this case it is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.</li>
|
||||
<li>The MIX service generates the nick. </li>
|
||||
</ol>
|
||||
<p>
|
||||
A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a <setnick/> child element of <iq/> element. The <setnick/> element is qualified by the 'urn:xmpp:mix:core:0' namespace. The nick is encoded as a <nick/> child element of the <setnick/> element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.
|
||||
@ -1132,9 +1145,11 @@
|
||||
</p>
|
||||
<ol>
|
||||
<li>A <nick> element that contains the Nick of the message sender, taken from the Participants Node. This MUST be present if a Nick is defined for the user.</li>
|
||||
<li>A <jid> element containing the real JID of the sender. This MUST be present, unless following the "JID Hidden" model defined in MIX-ANON. If this element is omitted, the <nick> and <proxy-jid> elements MUST be present.</li>
|
||||
<li>A <proxy-jid> element contains the sender's proxy JID. This MUST be present if <jid> is omitted and MUST not be present if <jid> is present.</li>
|
||||
<li>A <jid> element containing the real JID of the sender. This MUST be present, unless following the "JID Hidden" model defined in MIX-ANON. If this element is omitted, the <nick> element MUST be present.</li>
|
||||
</ol>
|
||||
<p>
|
||||
MIX messages are distributed by the channel with the from using the JID of the channel, with the Stable Participant ID of the sender in the resource. This enables a receiving system to distinguish messages based on sender using on the JID.
|
||||
</p>
|
||||
<p>The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in
|
||||
standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server as specified in MIX-PAM. The message 'from' attribute is the JID of the channel. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' attribute.</p>
|
||||
|
||||
@ -1146,13 +1161,13 @@
|
||||
<body>Harpier cries: 'tis time, 'tis time.</body>
|
||||
<mix xmlns='urn:xmpp:mix:core:0'>
|
||||
<nick>thirdwitch</nick>
|
||||
<jid>123456#coven@mix.shakespeare.example</jid>
|
||||
<jid>hag66@shakespeare.example</jid>
|
||||
</mix>
|
||||
</message>
|
||||
]]></example>
|
||||
|
||||
<example caption="Channel Reflects Message to Participants"><![CDATA[
|
||||
<message from='coven@mix.shakespeare.example'
|
||||
<message from='coven@mix.shakespeare.example/123456'
|
||||
to='hecate@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
@ -1164,23 +1179,12 @@
|
||||
</message>
|
||||
]]></example>
|
||||
|
||||
<example caption="Channel Reflects Message to Participants with Proxy JID"><![CDATA[
|
||||
<message from='coven@mix.shakespeare.example'
|
||||
to='hecate@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
<body>Harpier cries: 'tis time, 'tis time.</body>
|
||||
<mix xmlns='urn:xmpp:mix:core:0'>
|
||||
<nick>thirdwitch</nick>
|
||||
<proxy-jid>123456#coven@mix.shakespeare.example</proxy-jid>
|
||||
</mix>
|
||||
</message>
|
||||
]]></example>
|
||||
|
||||
<p>
|
||||
The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional <submission-id> element in the <mix> element of the message copy going back to the originator's bare JID. The <submission-id> element holds the original id provided by the sender. This enables the originator to correlate the received message with the message submitted.
|
||||
</p>
|
||||
<example caption="Channel Reflects Message back to Originator"><![CDATA[
|
||||
<message from='coven@mix.shakespeare.example'
|
||||
<message from='coven@mix.shakespeare.example/123456'
|
||||
to='hag66@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
@ -1362,7 +1366,7 @@
|
||||
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>MIX is built over MAM and PubSub and the security considerations of &xep0313; and &xep0060; MUST be considered. These services protect MIX channel information, which can be sensitive and needs appropriate protection.</p>
|
||||
<p>MIX channels MAY be JID Hidden, in order to hide the JIDs of channel participants from those accessing the channel. Care MUST be taken to ensure that JIDs are fully hidden. In particular when proxy JIDs are prepared, this MUST be done in a manner which ensure that the real JIDs cannot be determined. Where nicks are assigned by a channel, this MUST be done in a way that does not expose the JID.</p>
|
||||
|
||||
<p>
|
||||
There is no MIX equivalent to &xep0045; password controlled rooms, which avoids a number of security issues.
|
||||
</p>
|
||||
|
||||
190
xep-0403.xml
190
xep-0403.xml
@ -8,7 +8,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Mediated Information eXchange (MIX): Presence Support.</title>
|
||||
<abstract>This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369 to provide presence information for MIX clients to MIX channel participants. </abstract>
|
||||
<abstract>This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369 to provide presence information for MIX clients to MIX channel participants. It also specifies relay of IQ stanzas through a MIX channel. </abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0403</number>
|
||||
<status>Experimental</status>
|
||||
@ -30,6 +30,7 @@
|
||||
<spec>XEP-0313</spec>
|
||||
<spec>XEP-0369</spec>
|
||||
<spec>XEP-0372</spec>
|
||||
<spec>XEP-0404</spec>
|
||||
<spec>XEP-0405</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
@ -38,6 +39,16 @@
|
||||
&ksmithisode;
|
||||
&skille;
|
||||
<revision>
|
||||
<version>0.2.0</version>
|
||||
<date>2018-06-05</date>
|
||||
<initials>sek</initials>
|
||||
<remark><p>
|
||||
Change JID Addressing of IQs and Presence;
|
||||
Clarify routing if IQs through channel;
|
||||
Add vCard routing;
|
||||
Add mix information to presence;
|
||||
</p></remark>
|
||||
</revision><revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2018-05-21</date>
|
||||
<initials>sek</initials>
|
||||
@ -50,6 +61,10 @@
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities for message distribution are specified in &xep0369; (MIX-CORE). This specification enables presence status of online clients belonging to channel participants to be shared through the channel with participants that wish to see this presence status. This is a achieved by a MIX presence node, which channel participants may subscribe to.
|
||||
</p>
|
||||
<p>
|
||||
MIX-CORE shares participant JIDs, which enables messages to be exchange directly.
|
||||
To facilitate communication between clients IQ stanza messages MAY be routed through a MIX channel. This is needed because many XMPP clients will block IQ stanzas from an unknown JID. Routing IQ stanzas avoids this.
|
||||
</p>
|
||||
|
||||
</section1>
|
||||
|
||||
@ -61,7 +76,8 @@
|
||||
<li>The mechanism must work cleanly for participants with multiple clients.</li>
|
||||
<li>Standard presence messages must be used to share presence.</li>
|
||||
<li>Nick changes should be visible as changes (and not as a new user).</li>
|
||||
<li>Where &xep0404; is not used, participants must be able to directly contact other participants.</li>
|
||||
<li>Where &xep0404; (MIX-ANON) is not used, participants must be able to directly contact other participants.</li>
|
||||
<li>IQ stanzas, including vCard, can be communicated through a channel.</li>
|
||||
|
||||
</ol>
|
||||
|
||||
@ -69,24 +85,40 @@
|
||||
|
||||
<section1 topic='Concepts' anchor='concepts'>
|
||||
|
||||
<section2 topic="Participant Information in Presence" anchor="concept-participant-info">
|
||||
<p>
|
||||
A MIX channel MAY distribute presence information about channel participants. In order to share JID and Nick information about a participant, this information is encoded in the presence message. This allows full presence information to be shared for each participant without the need for the client to perform any lookup.
|
||||
</p>
|
||||
</section2>
|
||||
|
||||
|
||||
|
||||
<section2 topic="Partipant JID Addressing for Presence and IQ relay" anchor="concept-jid-address">
|
||||
<p>
|
||||
Participants in Presence messages and in IQ messages relayed through a channel are identified by an encoded JID of the form are encoded, using the format "<stable-participant-identifier>#<channel>@<mix domain>". This provides a stable JID for each participant. This JID format is used in three places:
|
||||
</p>
|
||||
<ol>
|
||||
<li>The 'from' of presence stanzas generated by the channel.</li>
|
||||
<li>The 'to' of IQ stanzas being sent to the channel.</li>
|
||||
<li>The 'from' of IQ stanzas coming from the channel.</li>
|
||||
</ol>
|
||||
<p>
|
||||
These JIDs will be used to represent specific JID clients. The resource associated with the encoded JID MUST be the resource value from the associated client JID, except where MIX-ANON is followed.
|
||||
</p>
|
||||
</section2>
|
||||
|
||||
|
||||
<section2 topic="User Presence in MIX" anchor="concepts-presence">
|
||||
<p>
|
||||
MIX channels store presence of each online client for a user that chooses to publish presence. Presence is stored in the presence node and is encoded using a full proxy JID. Where a user publishes presence for one or more clients, this information is available to all users subscribing to the channel presence.
|
||||
MIX channels store presence of each online client for a user that chooses to publish presence, in the format that is distributed as presence. Presence is stored in the presence node with an item for each client that is publishing presence. Each item is named with an encoded JID and contains the presence information that is distributed. Where a user publishes presence for one or more clients, this information is available to all users subscribing to the channel presence.
|
||||
</p>
|
||||
<p>
|
||||
A client participating in a MUC channel MAY send it's presences status to the MIX channel using standard presence. The mechanisms to do this are summarized in the next section and standardized in &xep0405;.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The MIX channel will distribute received presence to participants that have subscribed to the participants node. The client to which each presence update refers is identified by the <from> of the presence sent by the MIX channel. This is also the JID stored in the MIX presence node. This JID is built from two components:
|
||||
</p>
|
||||
<ol>
|
||||
<li>The bare proxy JID of the client, as specified in &xep0369;. This encodes channel and a stable random ID in a JID associated with the MIX domain, which enables it to be used for sending presence. </li>
|
||||
<li>The resource taken from the client’s full JID, except when &xep0404; is used, when the resource is hidden.</li>
|
||||
</ol>
|
||||
<p>
|
||||
A client receiving this presence can use information from the channel participant's node to derive the full JID of the client and an associated Nick. When &xep0404; is used to hide JIDs, only the Nick can be derived.
|
||||
The MIX channel will distribute received presence to participants that have subscribed to the participants node. The client to which each presence update refers is identified by the <from> of the presence sent by the MIX channel, using the encoded JID format.
|
||||
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@ -113,7 +145,7 @@
|
||||
|
||||
|
||||
|
||||
<section2 topic="Presence Node" anchor="prsence-node">
|
||||
<section2 topic="Presence Node" anchor="presence-node">
|
||||
<p>MIX defines one node to support presence, as summarized in the table below. This node is required to support this specification.</p>
|
||||
<table caption="MIX Presence Node">
|
||||
<tr><th>Name</th><th>Node</th><th>Description</th><th>Update</th><th>Distribution</th></tr>
|
||||
@ -126,16 +158,27 @@
|
||||
|
||||
|
||||
<p>
|
||||
The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence, so that active channel participants are visible. It is not possible to enforce this in the server, so participants in a channel with this option MUST publish presence. Each item in the presence node is identified by a JID constructed from the proxy JID and the resource for the client. The presence is encoded as a standard a presence stanza using a <presence/> element qualified by the 'jabber:client' namespace.
|
||||
The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence, so that active channel participants are visible. It is not possible to enforce this in the server, so participants in a channel with this option MUST publish presence. Each item in the presence node is identified by an encoded JID. The presence is encoded as a standard a presence stanza using a <presence/> element qualified by the 'jabber:client' namespace.
|
||||
</p>
|
||||
<p>
|
||||
MIX extends the <presence> stanza using a <mix> element qualified by the 'urn:xmpp:mix:presence:0' namespace. This enables any receiver of presence to see identify the client to which presence refers and to have a nick to display. This element contains two child elements:
|
||||
</p>
|
||||
<ol>
|
||||
<li>A <nick> element that contains the Nick of the message sender, taken from the Participants Node. This MUST be present if a Nick is defined for the user.</li>
|
||||
<li>A <jid> element containing the full JID of the client. This MUST be present, unless following the "JID Hidden" model defined in MIX-ANON. If this element is omitted, the <nick> element MUST be present.</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
This node MAY be subscribed to by users using the user's bare JID. So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and MUST NOT be sent using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub. The Presence node is a permanent PubSub node. The following example shows a presence node value for the full JID 'hecate@shakespeare.example/UUID-x4r/2491'.
|
||||
This node MAY be subscribed to by users using the user's bare JID. So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and MUST NOT be sent using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub. The Presence node is a permanent PubSub node. The following example shows a presence node value for the client with full JID 'hecate@shakespeare.example/UUID-x4r/2491'.
|
||||
</p>
|
||||
<example caption="Value of Presence Node"><![CDATA[
|
||||
<items node='urn:xmpp:mix:nodes:presence'>
|
||||
<item id='123456#coven@mix.shakespeare.example/UUID-x4r/2491'>
|
||||
<presence xmlns='jabber:client'>
|
||||
<mix xmlns='urn:xmpp:presence:0'>
|
||||
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
|
||||
<nick>thirdwitch</jid>
|
||||
</mix>
|
||||
<show>dnd</show>
|
||||
<status>Making a Brew</status>
|
||||
</presence>
|
||||
@ -152,10 +195,10 @@
|
||||
|
||||
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Common User Use Cases' anchor='usecases-user'>
|
||||
|
||||
|
||||
<section3 topic='Setting User Presence' anchor='usecase-user-presence'>
|
||||
|
||||
<section2 topic='Setting User Presence' anchor='usecase-user-presence'>
|
||||
<p>
|
||||
|
||||
A user joins a channel over an extended period, and participation in a channel does not generally change when user goes online or offline. The user's participation in a channel is reflected by the user's bare JID in the participant node. All messages to the channel are sent to this JID.
|
||||
@ -191,12 +234,16 @@ A user MAY share presence information with the channel, for one or more online c
|
||||
<show>dnd</show>
|
||||
<status>Making a Brew</status>
|
||||
</presence>]]></example>
|
||||
<p>The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node. The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the full proxy JID of the client updating status.
|
||||
<p>The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node. The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza 'from' uses an encoded JID.
|
||||
Note that presence is associated with a client and so will have a full JID. The following example shows a presence message as distributed by the server to a presences subscriber.</p>
|
||||
<example caption="Channel Distributes Presence">
|
||||
<![CDATA[<presence from='123435#coven@mix.shakespeare.example/UUID-a1j/7533'
|
||||
<![CDATA[<presence from='123435#coven@mix.shakespeare.example/UUID-a1j/7533'
|
||||
to='hag99@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
|
||||
<mix xmlns='urn:xmpp:presence:0'>
|
||||
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
|
||||
<nick>thirdwitch</jid>
|
||||
</mix>
|
||||
<show>dnd</show>
|
||||
<status>Making a Brew</status>
|
||||
</presence>]]></example>
|
||||
@ -207,40 +254,45 @@ A user MAY share presence information with the channel, for one or more online c
|
||||
<p>
|
||||
The history of the presence node MAY be archived using MAM. The MAM archive stores the node in PubSub format, following the node specification. This enables presence history to be retrieved using PubSub.
|
||||
</p>
|
||||
</section3>
|
||||
</section2>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<section3 topic="Client Coming Online and Obtaining Presence from the Local Server" anchor="usecase-obtaining-presence">
|
||||
<section2 topic="Client Coming Online and Obtaining Presence from the Local Server" anchor="usecase-obtaining-presence">
|
||||
<p>
|
||||
MIX Clients obtain presence from their local server. This is specified in &xep0405;.
|
||||
|
||||
</p>
|
||||
|
||||
|
||||
</section3>
|
||||
</section2>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<section3 topic='Going Offline' anchor='usecase-user-offline'>
|
||||
<section2 topic='Going Offline' anchor='usecase-user-offline'>
|
||||
<p>When a client goes offline, this presence update is sent by the client's server to the MIX channel. From the client perspective, this is the same as any other presence change. The MIX Channel also needs to remove the client from the participant's node.</p>
|
||||
<example caption="Client Goes Offline in the Channel"><![CDATA[
|
||||
<presence type='unavailable'
|
||||
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 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>
|
||||
<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 use the encoded 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/UUID-a1j/7533'
|
||||
<![CDATA[<presence from='12345#coven@mix.shakespeare.example/UUID-a1j/7533'
|
||||
to='hecate@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='unavailable'/>]]></example>
|
||||
type='unavailable'>
|
||||
<mix xmlns='urn:xmpp:presence:0'>
|
||||
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
|
||||
<nick>thirdwitch</jid>
|
||||
</mix>
|
||||
</presence>]]></example>
|
||||
|
||||
<p>
|
||||
There is the possibility that the message associated with the user going offline will be lost. If this happens, "ghost" entries will appear in the presence node. A MIX service MAY take steps to address this, for example by probing client with a disco for presence items that remain unchanged for a long period.
|
||||
@ -248,23 +300,97 @@ A user MAY share presence information with the channel, for one or more online c
|
||||
|
||||
|
||||
|
||||
</section3>
|
||||
</section2>
|
||||
|
||||
<section3 topic="User Leaving a Channel" anchor="usecase-presence-leave">
|
||||
<section2 topic="User Leaving a Channel" anchor="usecase-presence-leave">
|
||||
<p>
|
||||
The primary actions for a user leaving a channel are specified in &xep0369;. This section sets out additional actions for handling presence. When a user leaves the channel, all entries for the user's clients MUST be removed from the participants node. The MIX channel MUST distribute unavailable presence notifications for each client removed to all subscribers of the participants node.
|
||||
</p>
|
||||
|
||||
<example caption="Channel Distributes Notification when User Leaves Channel">
|
||||
<![CDATA[<presence from='12345#coven@mix.shakespeare.example/UUID-a1j/7533'
|
||||
<![CDATA[<presence from='12345#coven@mix.shakespeare.example/UUID-a1j/7533'
|
||||
to='hecate@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='unavailable'/>]]></example>
|
||||
|
||||
|
||||
</section3>
|
||||
type='unavailable'>
|
||||
<mix xmlns='urn:xmpp:presence:0'>
|
||||
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
|
||||
<nick>thirdwitch</jid>
|
||||
</mix>
|
||||
</presence>]]></example>
|
||||
|
||||
</section2>
|
||||
|
||||
|
||||
<section2 topic="Relaying IQ Stanzas" anchor="usecase-iq-relay">
|
||||
<p>
|
||||
MIX channels MAY relay IQ stanzas between participants. This is often useful to obtain client information where a direct request to the client would be blocked. When a client sends an IQ stanza through a MIX channel, it will set the 'from' to its own JID and set the 'to' to the encoded JID of the recipient. The MIX channel will modify the JIDs in the outgoing message, so that the 'to' is the full JID of the recipient and the 'from' is the encoded JID of the sender. This is illustrated in the vCard section below.
|
||||
</p>
|
||||
</section2>
|
||||
|
||||
|
||||
|
||||
<section2 topic="Requesting a vCard through a Channel" anchor="usecase-vcard">
|
||||
<p>A client MAY request the vCard of a channel participant through a MIX channel, for example to get an avatar. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). The MIX channel does not process the vCard requests, but simply relays them on to real bare JID of the target. A MIX service MAY choose to relay one or both protocols. Where a MIX service relays one or both of these protocols, each protocol relayed MUST be advertised as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the encoded JID of the channel participant for which the vCard is desired.</p>
|
||||
<example caption="Client directly requests vCard through channel" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
id='lx09df27'
|
||||
to='989898#coven@mix.shakespeare.example'
|
||||
type='get'>
|
||||
<vCard xmlns='vcard-temp'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The MIX channel MAY pass on the vCard request or MAY reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the user's server (using bare JID) using an the encoded JID of the requester in the 'from'. </p>
|
||||
<example caption="Channel passes on vCard request to the User's Server" ><![CDATA[
|
||||
<iq from='123456#coven@mix.shakespeare.example/6789'
|
||||
id='lx09df27'
|
||||
to='peter@shakespeare.example'
|
||||
type='get'>
|
||||
<vCard xmlns='vcard-temp'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>
|
||||
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.example'
|
||||
id='lx09df27'
|
||||
to='123456#coven@mix.shakespeare.example/6789'
|
||||
type='result'>
|
||||
<vCard xmlns='vcard-temp'>
|
||||
<FN>Peter Saint-Andre</FN>
|
||||
<N>
|
||||
<FAMILY>Saint-Andre</FAMILY>
|
||||
<GIVEN>Peter</GIVEN>
|
||||
<MIDDLE/>
|
||||
</N>
|
||||
<NICKNAME>stpeter</NICKNAME>
|
||||
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
|
||||
</vCard>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>
|
||||
The MIX channel will then send the vCard response to the requesting client on behalf of the client sending the response.
|
||||
</p>
|
||||
<example caption="MIX Channel sends vCard responst to Client" ><![CDATA[
|
||||
<iq from='989898#coven@mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
type='result'>
|
||||
<vCard xmlns='vcard-temp'>
|
||||
<FN>Peter Saint-Andre</FN>
|
||||
<N>
|
||||
<FAMILY>Saint-Andre</FAMILY>
|
||||
<GIVEN>Peter</GIVEN>
|
||||
<MIDDLE/>
|
||||
</N>
|
||||
<NICKNAME>stpeter</NICKNAME>
|
||||
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
|
||||
</vCard>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
|
||||
</section1>
|
||||
|
||||
|
||||
|
||||
128
xep-0404.xml
128
xep-0404.xml
@ -37,6 +37,17 @@
|
||||
<shortname>MIX-ANON</shortname>
|
||||
&ksmithisode;
|
||||
&skille;
|
||||
<revision>
|
||||
<version>0.2.0</version>
|
||||
<date>2018-06-05</date>
|
||||
<initials>sek</initials>
|
||||
<remark><p>
|
||||
Remove vCard (now in MIX-PRESENCE);
|
||||
Update PM rules;
|
||||
Reflect changes in MIX-CORE and MIX-PRESENCE;
|
||||
New JID map format;
|
||||
</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2018-05-21</date>
|
||||
@ -65,8 +76,8 @@
|
||||
<section2 topic="Private Messages" anchor="concepts-pm">
|
||||
<p>
|
||||
&xep0369; exposes participant JIDs to other participants, and so messages can always be sent directly. When JIDs are hidden this is no longer possible.
|
||||
Private messages MAY be sent to channel participants if allowed by channel policy. Private messages are
|
||||
addressed to the user's bare proxy JID determined from the participants node, and routed by the MIX to the user's bare real JID, where standard distribution rules will apply.
|
||||
Private messages MAY be sent to channel participants if allowed by channel policy. Private messages are switched through the channel to hide addressing.
|
||||
|
||||
</p>
|
||||
|
||||
</section2>
|
||||
@ -100,12 +111,13 @@
|
||||
|
||||
<section2 topic="JID Visibility Architecture" anchor="proxy-jid-architecture">
|
||||
<p>
|
||||
MUC hides real JIDs by using Nicks to identify room occupants. This has problems with Nick changing and with multiple active clients for the same user. MIX identifies channel participants by a proxy JID, which is an anonymized stable JID format identifier for each participant. In &xep0369;, the participants node provides a mapping from the proxy JID to the real JID. To hide JIDs, this specification makes two key changes
|
||||
MUC hides real JIDs by using Nicks to identify room occupants. This has problems with Nick changing and with multiple active clients for the same user. MIX identifies channel participants by Stable Participant ID. In &xep0369;, the users JID is in the participants node and is shared in messages and presence. To hide JIDs, this specification makes three key changes
|
||||
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>The requirement to include real JID in the participants list is relaxed for channels that are not "JID Visible". For a "JID Hidden" channel, real JIDs MUST NOT be included in the participants list. For a "JID Maybe Visible" channel, real JIDs will be included in the participants node according to participant preference. </li>
|
||||
<li>JIDs are not shared in messages and presence.</li>
|
||||
<li>In presence messages, the client resource is anonymized, to prevent leakage of information through the resource.</li>
|
||||
</ol>
|
||||
|
||||
@ -116,7 +128,7 @@ This change means that the client will not be able to determine real JID of the
|
||||
</p>
|
||||
|
||||
<p>
|
||||
It is important that MUC owners and administrators are able to see the real JIDs of participant. For this reason, a MIX channel following this specification MUST hold a JID Map node, which gives a mapping between proxy JID and real JID.
|
||||
It is important that MUC owners and administrators are able to see the JIDs of participant. For this reason, a MIX channel following this specification MUST hold a JID Map node, which gives a mapping between Stable Participant ID and JID.
|
||||
</p>
|
||||
|
||||
|
||||
@ -132,16 +144,16 @@ This change means that the client will not be able to determine real JID of the
|
||||
|
||||
<p>
|
||||
When JIDs are being hidden, the resource of the full JIDs stored in the presence node MUST also be anonymized using a similar mechanism.
|
||||
First the bare JID in presence is a proxy JID, as defined in &xep0369;. Where the JID is not being hidden, the resource is simply the resource of the clients full JID. Where the JID is hidden, the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an full proxy JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID.
|
||||
Where the JID is not being hidden, the resource is simply the resource of the clients full JID. Where the JID is hidden, the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have an encoded JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping maintained, as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an encoded JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID.
|
||||
</p>
|
||||
</section2>
|
||||
|
||||
|
||||
<section2 topic="JID Map Node" anchor="concepts-nodes">
|
||||
<p>This specification defines a JID Map node, so that administrators can see real JIDs for JID Hidden channels.</p>
|
||||
<p>This specification defines a JID Map node, so that administrators can see JIDs for JID Hidden channels.</p>
|
||||
<table caption="JID Map Node">
|
||||
|
||||
<tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td><td>Automatic</td><td>PubSub</td></tr>
|
||||
<tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of Stable Participant IDs from the participants node with a 1:1 mapping to the corresponding JIDs.</td><td>Automatic</td><td>PubSub</td></tr>
|
||||
|
||||
</table>
|
||||
|
||||
@ -149,12 +161,12 @@ This change means that the client will not be able to determine real JID of the
|
||||
|
||||
|
||||
|
||||
<p>The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel.
|
||||
Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub.
|
||||
In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:anon:0' namespace. The real JID is stored in a <jid/> child element of the <participant/> element. </p>
|
||||
<p>The JID Map node is used to associate a Stable Participant ID to its corresponding bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel.
|
||||
Each item is identified by Stable Participant ID mapping to the bare JID. This node is used to give administrator access to JIDs. This node MUST NOT be modified directly using pubsub.
|
||||
Only administrators can subscribe to this node. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:anon:0' namespace. The real JID is stored in a <jid/> child element of the <participant/> element. </p>
|
||||
<example caption="Value of JID Map Node"><![CDATA[
|
||||
<items node='urn:xmpp:mix:nodes:jidmap'>
|
||||
<item id='123456#coven@mix.shakespeare.example'>
|
||||
<item id='123456'>
|
||||
<participant xmlns='urn:xmpp:mix:anon:0'>
|
||||
<jid>hecate@mix.shakespeare.example</jid>
|
||||
</participant>
|
||||
@ -337,84 +349,34 @@ This change means that the client will not be able to determine real JID of the
|
||||
<section2 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, where the initiating user does not 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.
|
||||
Private Messages are used to provide communication with another channel participant through the MIX channel, where the initiating user does not know the real JID of the channel participant. A message is addressed to the channel using the encoded JID of the client to which the message is being sent. This is shown in the following example.
|
||||
</p>
|
||||
<table caption="Setting From and To when sending Private Messages">
|
||||
<tr><th>Message</th><th>From</th><th>To</th></tr>
|
||||
<tr><td>First Message from Client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy bare JID of responder</td></tr>
|
||||
<tr><td>First Message from MIX Channel to responder's server</td><td>Proxy full JID of initiator's client</td><td>Bare JID of responder</td></tr>
|
||||
<tr><td>First Message from responder's server to one or more of the responder's clients</td><td>Proxy full JID of initiator</td><td>Full JID of responder's client</td></tr>
|
||||
<tr><td>Messages from responder's client to MIX Channel</td><td>Full JID of responder's client</td><td>Proxy full JID of initiator's client</td></tr>
|
||||
<tr><td>Messages from MIX channel to initiator's client</td><td>Proxy full JID of responder's client</td><td>Full JID of initiator's client</td></tr>
|
||||
<tr><td>Messages from initiator's client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy full JID of responder's client</td></tr>
|
||||
<tr><td>Message from MIX Channel to responder's client</td><td>Proxy full JID of initiator's client</td><td>Full JID of responder's client</td></tr>
|
||||
</table>
|
||||
|
||||
<example caption="User Sends a Private Message"><![CDATA[
|
||||
<message from='hag66@shakespeare.example/UUID-a1j/7533'
|
||||
to='444456#coven@mix.shakespeare.example/4588'
|
||||
id='92vax143g'>
|
||||
<body>Private meeting about Macbeth???</body>
|
||||
</message>
|
||||
]]></example>
|
||||
|
||||
<p>
|
||||
The MIX channel will then process the message, to send to the real JID of the recipient. An encoded JID is used to identify the message sender.
|
||||
</p>
|
||||
|
||||
<example caption="MIX Channel Sends Private Message to Recipient"><![CDATA[
|
||||
<message from='123456#coven@mix.shakespeare.example/9988'
|
||||
to='hag99@shakespeare.example/UUID-a1j/7533'
|
||||
id='92vax143g'>
|
||||
<body>Private meeting about Macbeth???</body>
|
||||
</message>
|
||||
]]></example>
|
||||
|
||||
<p>Private Messages MAY be archived using MAM by the XMPP servers associated with initiator and responder. Private Messages MUST NOT be archived by the MIX channel.</p>
|
||||
</section2>
|
||||
|
||||
|
||||
|
||||
<section2 topic="Requesting vCard" anchor="usecase-vcard">
|
||||
<p>A client MAY request the vCard of a channel participant where the participant's real JID is not known, by sending a request through the channel. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). The MIX channel does not process the vCard requests, but simply relays them on to real bare JID of the target. A MIX service MAY choose to relay one or both protocols. Where a MIX service relays one or both of these protocols, each protocol relayed MUST be advertised as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the bare proxy JID of the channel participant for which the vCard is desired.</p>
|
||||
<example caption="Client directly requests vCard through channel" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
id='lx09df27'
|
||||
to='989898#coven@mix.shakespeare.example'
|
||||
type='get'>
|
||||
<vCard xmlns='vcard-temp'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The MIX channel MAY pass on the vCard request or MAY reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the user's server (using bare JID) using a full proxy JID to hide the requester. </p>
|
||||
<example caption="Channel passes on vCard request to the User's Server" ><![CDATA[
|
||||
<iq from='123456#coven@mix.shakespeare.example/6789'
|
||||
id='lx09df27'
|
||||
to='peter@shakespeare.example'
|
||||
type='get'>
|
||||
<vCard xmlns='vcard-temp'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>
|
||||
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.example'
|
||||
id='lx09df27'
|
||||
to='123456#coven@mix.shakespeare.example/6789'
|
||||
type='result'>
|
||||
<vCard xmlns='vcard-temp'>
|
||||
<FN>Peter Saint-Andre</FN>
|
||||
<N>
|
||||
<FAMILY>Saint-Andre</FAMILY>
|
||||
<GIVEN>Peter</GIVEN>
|
||||
<MIDDLE/>
|
||||
</N>
|
||||
<NICKNAME>stpeter</NICKNAME>
|
||||
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
|
||||
</vCard>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>
|
||||
The MIX channel will then send the vCard response to the requesting client on behalf of the client sending the response.
|
||||
</p>
|
||||
<example caption="MIX Channel sends vCard responst to Client" ><![CDATA[
|
||||
<iq from='989898#coven@mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
type='result'>
|
||||
<vCard xmlns='vcard-temp'>
|
||||
<FN>Peter Saint-Andre</FN>
|
||||
<N>
|
||||
<FAMILY>Saint-Andre</FAMILY>
|
||||
<GIVEN>Peter</GIVEN>
|
||||
<MIDDLE/>
|
||||
</N>
|
||||
<NICKNAME>stpeter</NICKNAME>
|
||||
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
|
||||
</vCard>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
|
||||
</section1>
|
||||
|
||||
|
||||
36
xep-0405.xml
36
xep-0405.xml
@ -37,6 +37,14 @@
|
||||
<shortname>MIX-PAM</shortname>
|
||||
&ksmithisode;
|
||||
&skille;
|
||||
<revision>
|
||||
<version>0.1.1</version>
|
||||
<date>2018-06-05</date>
|
||||
<initials>sek</initials>
|
||||
<remark><p>
|
||||
Align to MIX-CORE and MIX-PRESENCE changes;
|
||||
</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2018-05-21</date>
|
||||
@ -105,7 +113,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
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 &xep0369;, 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'
|
||||
<message from='coven@mix.shakespeare.example/123456'
|
||||
to='hecate@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
@ -124,7 +132,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</p>
|
||||
|
||||
<example caption="Participant's Server Sends Modified Message to two Clients"><![CDATA[
|
||||
<message from='coven@mix.shakespeare.example'
|
||||
<message from='coven@mix.shakespeare.example/123456'
|
||||
to='hecate@shakespeare.example/UUID-x4r/2491'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
@ -135,7 +143,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</mix>
|
||||
</message>
|
||||
|
||||
<message from='coven@mix.shakespeare.example'
|
||||
<message from='coven@mix.shakespeare.example/123456'
|
||||
to='hecate@shakespeare.example/UUID-b5b/0114'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
@ -396,7 +404,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<p>
|
||||
A user setting status is now used as an example. Unlike in &xep0045; where coming online is a special action, coming online in MIX is implicit when presence status is set. Going offline is a achieved by setting presence status to unavailable, which removes the client full JID entry from the presence node. When a user sets a presence status, the user's server sends updated presence to the MIX channel, and the MIX service then publishes the user's availability to the presence node. If there is not an item named by the full JID of the client with updated presence status, this item is created. The sequence is shown in the following examples, starting with a client setting presences status on the connected server.</p>
|
||||
<example caption="Client Sets Presence Status on Server">
|
||||
<![CDATA[<presence xmlns='jabber:client' from='hag66@shakespeare.example/UUID-a1j/7533'>
|
||||
<![CDATA[<presence xmlns='jabber:client' from='hag66@shakespeare.example/UUID-a1j/7533'>
|
||||
<show>dnd</show>
|
||||
<status>Making a Brew</status>
|
||||
</presence>]]></example>
|
||||
@ -405,7 +413,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
The server then sends the presence information to roster entries. The following example then shows the presence message from the client's server to the MIX channel. The presence is then handled as specified in &xep0369;.
|
||||
</p>
|
||||
<example caption="Server sends Presence Status to MIX Channel">
|
||||
<![CDATA[<presence from='hag66@shakespeare.example/UUID-a1j/7533'
|
||||
<![CDATA[<presence from='hag66@shakespeare.example/UUID-a1j/7533'
|
||||
to='coven@mix.shakespeare.example'>
|
||||
<show>dnd</show>
|
||||
<status>Making a Brew</status>
|
||||
@ -421,6 +429,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<![CDATA[<presence from='123435#coven@mix.shakespeare.example/UUID-a1j/7533'
|
||||
to='hag99@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
|
||||
<mix xmlns='urn:xmpp:presence:0'>
|
||||
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
|
||||
<nick>thirdwitch</jid>
|
||||
</mix>
|
||||
<show>dnd</show>
|
||||
<status>Making a Brew</status>
|
||||
</presence>]]></example>
|
||||
@ -431,6 +443,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<![CDATA[<presence from='123435#coven@mix.shakespeare.example/UUID-a1j/7533'
|
||||
to='hag99@shakespeare.example/UUID-rrr/1234'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
|
||||
<mix xmlns='urn:xmpp:presence:0'>
|
||||
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
|
||||
<nick>thirdwitch</jid>
|
||||
</mix>
|
||||
<show>dnd</show>
|
||||
<status>Making a Brew</status>
|
||||
</presence>]]></example>
|
||||
@ -440,9 +456,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
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, even when there are no online clients. When a user had no online clients the user's server MAY continue to maintain MIX presence status for the user or MAY discard inbound MIX presence information.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The client receiving the presence can parse the proxy JID, specified in &xep0369; to identify the channel to which the message relates. The proxy JID can be looked up in the Participant's node to determine Nick and real bare JID. The real bare JID can be combined with the resource form the presence stanza to determine the full real JID of the sender. This is described in &xep0369;.
|
||||
</p>
|
||||
|
||||
</section3>
|
||||
|
||||
|
||||
@ -464,14 +478,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
The second scenario is when the MIX participant's server needs to load or refresh presence status for a channel. This will be needed when the participant's server is started or when the server chooses to not maintain presence for a user when all clients go offline. This MIX participant's server requests presence update by sending a directed presence stanza to the MIX channel from the user's bare JID. The MIX channel can distinguish this from a presence update, which will always be sent from the clients full JID. This will cause the MIX channel to send a full presence update for the channel.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
|
||||
<p>
|
||||
Presence information is provided with a proxy JID. A MIX client will usually wish to map this to the real JID. This will be done using the participants node, which has a list of all participants identified by proxy JID with real JIDs where this can be shared. Where real JIDs are not available, the Nick will be available. Clients will typically load the participants node on start-up and use a subscription to the participants node to keep this up to date.
|
||||
|
||||
|
||||
</p>
|
||||
</section3>
|
||||
|
||||
|
||||
<section3 topic='Going Offline' anchor='usecase-user-offline'>
|
||||
<p>When a client goes offline, this presence update is sent by the client's server to the MIX channel. From the client perspective, this is the same as any other presence change. Going online and offline will simply be presence updates. </p>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user