From 30cd35b610da721980e6a8c7f4bc994f605136d5 Mon Sep 17 00:00:00 2001
From: Steve Kille Historical data (such as the messages sent to the channel) is stored in an archive supporting Message Archive Management (MAM) so that clients can subsequently access this data with MAM. Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve archived information with MAM in order to quickly resync messages with regard to a channel, and can do so without providing presence information.
- A MIX channel does not send messages and presence directly to an XMPP MIX client. Instead it sends them to a MIX Proxy, which runs on the server which a MIX client accesses. MIX clients MUST make use of a MIX Proxy. Use of a MIX proxy enables flexible support of multiple clients for an XMPP user.
- The primary model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID. The MIX channel will send messages and presences to the MIX Proxy using the bare JID. The MIX Proxy will then send the messages and presence information to zero or more clients.
- The MIX Proxy provides a number of functions.
+ A MIX channel does not send messages and presence directly to an XMPP MIX client of a channel participant, but addresses them to participant using the participant's bare JID. The participant's server must then handle these messages and pass them on to zero, one or multiple clients. To enable MIX to work, this behaviour is necessary and so the server of every MIX client must follow the rules set out in this specification.
+This approach enables flexible support of multiple clients for a MIX channel participant.
+ The MIX model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID.
+ There are a number of MIX requirements on behaviour of the MIX Participant's server, which are summarized here:
- Messages being sent from MIX channel to MIX Proxy (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX Proxy will use a modification of the standard &rfc6121; rules.
+ Messages being sent from MIX channel to a MIX participant’s server (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX participant's server MUST support a modification of the standard &rfc6121; rules.
- The MIX standard specifies how the MIX channel interacts directly with XMPP clients and with the MIX Proxy. MIX Proxy behaviour is also specified in this MIX specification.
+ The core MIX specification sets out how the MIX channel interacts directly with XMPP clients and with the MIX participant's server. Behaviour of the MIX participant's server is also specified in this MIX specification.
-
- This node may be subscribed to by users and this subscription MUST use the users bare JID. So presence of online clients is sent to the MIX Proxy for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub. + This node may be subscribed to by users and this subscription MUST use the users 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 NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub.
- When a user subscribes to the Subject Node, this will cause the channel to send Subject messages to the user through the MIX Proxy. This is done on initial user subscription and on subject change. Clients MAY directly read the channel subject from the Subject Node using PubSub. + When a user subscribes to the Subject Node, this will cause the channel to send Subject messages to the user's server using the user's bare JID. This is done on initial user subscription and on subject change. Clients MAY directly read the channel subject from the Subject Node using PubSub.
A MIX service MUST NOT advertise support for &xep0313;, as MAM is supported by the channels and not by the service. A MIX service MUST NOT advertise support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service.
The list of channels supported by a MIX service is obtained by a disco#items command. The MIX service MUST only return channel that exist and that the user making the query has rights to subscribe to. This query MAY be made directly by and XMPP client or by a MIX Proxy.
-In order to find out more information about a given channel, a user can send a disco#info query to the channel. This query MUST be made by a MIX Proxy and not the end client.
+In order to find out more information about a given channel, a user can send a disco#info query to the channel. This query MUST be made by the user's server and not the end client.
Note that this query comes from the bare JID to the MIX channel, as it will always be sent to the MIX service by a MIX proxy. 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 rad results returned MUST include 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.
+Note that this query comes from the bare JID to the MIX channel, as it will always be sent to the MIX service by the user's server. 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 rad results returned MUST include 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.
Use disco#items to find the nodes associated with a channel. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. This query MUST be made by a MIX Proxy and not the end client.
+Use disco#items to find the nodes associated with a channel. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. This query MUST be made by the user's server and not the end client.
The Information Node contains various information about the channel that may be useful to the user. This can be read by the XMPP Client directly or by a MIX Proxy.
-Online clients in the channel are determined from the presence node. Participants in the channel are determined from the Participants Node which will give proxy JID and nick. The jidmap node is used to map to real JIDs. An operation is provided to list channel participants. For JID Hidden channels, only the nicks are returned. For JID Visible channels, nicks and real JIDs are returned.
-- After the user has jointed the channel, the user's MIX Proxy MAY add the MIX channel to the user's roster using standard XMPP to update the roster. This is done to share the user's presence status with the channel and so the MIX channel will get presence information from the user. This roster entry will lead to the user's server correctly sending user's presence from all clients to the MIX channel. The roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel. The user's MIX Proxy MUST remove this roster entry after the user leaves the channel. + After the user has jointed the channel, the user's server MAY add the MIX channel to the user's roster using standard XMPP to update the roster. This is done to share the user's presence status with the channel and so the MIX channel will get presence information from the user. This roster entry will lead to the user's server correctly sending user's presence from all clients to the MIX channel. The roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel. The user's server MUST remove this roster entry after the user leaves the channel.
If the user does not wish to publish presence information to the channel, the user will not add the roster entry. A channel may require presence to be provided by all channel participants, which is controlled by the 'Participants Must Provide Presence' option. The channel MAY check that channel participants have done this and MAY remove participants that do not do this.
@@ -1205,7 +1206,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID. 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 proxy (anonymized) full JID of the user. - Note that presence is associated with a client and so will have a full JID as it comes directly from the client and not through the MIX Proxy.
+ Note that presence is associated with a client and so will have a full JID as it comes directly from the client and not from the user's server.- The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to the MIX Proxy of users subscribing to this presence node. The user's MIX Proxy 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 MIX Proxy, and so the MIX Proxy will 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.
- When the client comes online, it will activate use of the MIX Proxy. The MIX Proxy 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. + 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.
- In normal operation the MIX Proxy will hold accurate presence status for the channel which it provides to clients when they are activated. Incoming presence updates are immediately sent to active MIX clients. + In normal operation a MIX participant's server will hold accurate presence status for the channel which it provides to clients when they are activated. Incoming presence updates are immediately sent to active MIX clients.
- There are two situations where the MIX Proxy will need to get presence status from the channel. The first time is when a user joins the channel as a participant and subscribes to presence. Upon this subscription the MIX channel will send to the MIX Proxy (the user's bare JID) presence for all of the items in the presence node using standard presence stanzas. This will give the MIX Proxy full current presence for the channel. + There are two situations where a MIX participant's server will need to get presence status from the channel. The first time is when a user joins the channel as a participant and subscribes to presence. Upon this subscription the MIX channel will send to the participant's server (using the user's bare JID) presence for all of the items in the presence node using standard presence stanzas. This will give the participant's full current presence for the channel.
- The second scenario is when the MIX Proxy needs to load or refresh presence status for a channel. This will be needed when the MIX Proxy and associated server are started. This MIX Proxy 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 special presence stanza will send to the MIX Proxy (the user's bare JID) presence for all of the items in the presence node using standard presence stanzas. + 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. 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 special presence stanza will send to the participant's server (using the user's bare JID) presence for all of the items in the presence node using standard presence stanzas.
A client sends a message directly to a MIX channel as a standard groupchat message, in exactly the same way as for &xep0045;. Messages are sent directly to the channel and do not use the MIX Proxy. The message id is selected by the client.
+A client sends a message directly to a MIX channel as a standard groupchat message, in exactly the same way as for &xep0045;. Messages are sent directly to the MIX channel from the user's client. The message id is selected by the client.
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 MIX Proxy. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender.
+ 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. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender.- This message is received by the MIX channel, which will set the Subject Node for the channel, and then distribute the message to participants that are subscribed to the Subject Node, with the message addressed to the MIX Proxy. + This message is received by the MIX channel, which will set the Subject Node for the channel, and then distribute the message to participants that are subscribed to the Subject Node, with the message addressed to the participant’s server using the participant's bare JID.
- When a new Participant joins a channel and subscribes to the Subject Node, the channel MUST send to the user's MIX Proxy a message with the current subject. An XMPP Client MAY directly read the Subject node using &xep0060;. + When a new Participant joins a channel and subscribes to the Subject Node, the channel MUST send to the participant's server (using the participant's bare JID) a message with the current subject. An XMPP Client MAY directly read the Subject node using &xep0060;.
Message | From | To |
---|---|---|
First Message from Client to MIX Channel | Full JID of initiator's client | Proxy bare JID of responder |
First Message from MIX Channel to responder's MIX Proxy | Proxy full JID of initiator's client | Bare JID of responder |
First Message from responder's MIX Proxy to one or more of the responder's clients | Proxy full JID of initiator | Full JID of responder's client |
First Message from MIX Channel to responder's server | Proxy full JID of initiator's client | Bare JID of responder |
First Message from responder's server to one or more of the responder's clients | Proxy full JID of initiator | Full JID of responder's client |
Messages from responder's client to MIX Channel | Full JID of responder's client | Proxy full JID of initiator's client |
Messages from MIX channel to initiator's client | Proxy full JID of responder's client | Full JID of initiator's client |
Messages from initiator's client to MIX Channel | Full JID of initiator's client | Proxy full JID of responder's client |