diff --git a/xep-0369.xml b/xep-0369.xml index 569891f8..a208e23a 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -40,7 +40,12 @@ &stpeter; - + + 0.3.1 + 2016-09-07 + sek +

Introduce MIX Proxy concept. Add MIX capability in client discovery.

 + 0.3 2016-09-05 @@ -143,7 +148,7 @@
  • Presence is sent to all participants using bare JID, whether or not the user has an online client.
  • Online clients MAY register presence, which is then shared with participants who have subscribed to presence.
  • MIX decouples addressing of occupants from their nicknames, so that nickname changes do not affect addressing.
    • -
  • 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 are then constructed, allowing visibility into the number of online resources participating in a channel.
    • +
  • 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.
  • MIX requires client support and server support from the server providing the MIX service. Although some protocol is shared with MUC, MUC clients are not interoperable with MIX servers. This means that where a user chooses to use MIX, all of the users clients need to support MIX.
    • @@ -154,24 +159,49 @@

    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.

     - -

    - 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 user will receive messages from the channel and/or access channel presence from time to time with one or more clients. + +

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

    +
      +
    1. Each MIX client will register with the MIX proxy. A key benefit of this approach is that MIX messages will only be sent to clients that support MIX. This enables use of clients that do not use MIX in conjunction with the MIX proxy.
      2. + +
    2. MIX Service and Channel subscription and management is handled by the MIX proxy. This means that all messages to MIX from the user use bare JID. Because the MIX Proxy is aware of subscription information, it can provide integrated support to a set of MIX clients.
      3. + +
    3. The MIX Proxy will only send messages to online clients and will discard messages if no clients are online. + This means that a MIX client needs to resynchronize with the MIX service when it comes online. This synchronization will happen directly between the MIX client and MIX channel.
      4. + +
    4. The MIX Proxy will know which channels are subscribed to, and so can provide a bookmark service to the MIX clients.
      5. + +
    5. The MIX Proxy will manage channel registration and de-registration in the user's roster.
      6. + +
    6. Different clients may wish to access different channels (e.g., a mobile client may only access a subset of the channels in which a user is interested). The MIX Proxy will handle sending messages only to the clients that wish for them.
      7. +

    - Where a user has no clients active, the approach is that all messages will be archived by the MIX channel (on arrival at the MIX channel) so that when clients come online they will use MAM to communicate to the MIX channel to access messages that have not been delivered to the client. Following the rules of &rfc6121;, arriving MIX messages (which will be of type=groupchat) and presence information will be discarded if all clients are offline. Offline messages are not used with MIX. This means that a MIX client needs to resynchronize with the MIX service when it comes online. + Arriving MIX messages (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.

    +

    - MIX delivery does not require any special support from the XMPP server to which the MIX client connects. When using a basic XMPP server for this service, all online clients for a user will receive the same set of messages and presence information, as MIX sends this information to the bare JID. + The MIX standard specifies how the MIX channel interacts directly with XMPP clients and with the MIX Proxy. +

    -     - - - +

    + The behaviour of a MIX Proxy and the protocol between MIX Proxy and MIX Client is not currently defined in this specification. It will be defined in one of three places. It may be desirable in some situations to provide different service to different clients. For example, a mobile client may participate in a smaller set of MIX channels than a desktop client. This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send. This is not supported by the core MIX specification, but it is anticipated that this will be supported by another specification. - This may be &xep0376; (PAM) or a new specification similar to PAM developed specifically in support of MIX. +

    +
      +
    1. In an extension to &xep0376; (PAM) which follows a model close to MIX Proxy; or
      2. + +
    2. In a new XEP specifically to defined MIX Proxy behavior; or
      3. + +
    3. As a new section in a future version of the MIX Specification.
      4. +
    + +

    QUESTION: Input is sought on the best place to standardize MIX Proxy.

    @@ -425,18 +455,18 @@

    In order to find out more information about a given channel, a user can send a disco#info query to the channel.

    ]]> -

    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.

    +

    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.

    Use disco#items to find the nodes associated with a channel. The MIX server MUST only return nodes that exist and that the user making the query has rights to subscribe to.

    @@ -462,7 +492,7 @@

    AUTHOR'S NOTE: Add example

     + + + + +

    + 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. The following example shows a Disco response from a client that supports both MIX and MUC. +

    + + + + + + + + + + + +]]> +     @@ -496,7 +551,7 @@

    The default MIX model is that only channel participants may subscribe to nodes. A MIX channel MAY allow non-participant subscription. This will be handled by clients directly subscribing to the desired PubSub nodes.

    @@ -508,11 +563,11 @@ ]]> -

    The channel must process the join atomically. The channel responds with an IQ-result. 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. 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 none of the nodes requested are successfully subscribed to, and error response is sent indicating the reason that the first node requested was not subscribed to. This response will also include other nodes requested where subscription failed for the same reason. A user may subsequently request subscription to nodes in a channel to which the user was not initially subscribed.

    +

    The channel responds with an IQ-result. 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. 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 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 response will also include other nodes requested where subscription failed for the same reason. A user may subsequently request subscription to nodes in a channel to which the user was not initially subscribed.

    @@ -526,7 +581,7 @@

    As noted, the participant might not be subscribed to all nodes associated with the channel (in this case only messages, participants, and subject).

    @@ -568,7 +623,7 @@
  • 'Prefer Not Show JID. If this is set, JID will only be shared if mode is JID-visible-mandatory.

    • - AUTHOR'S NOTE AND QUESTION: Dave Cridland has suggested. I would prefer: + AUTHOR'S NOTE AND QUESTION: Dave Cridland (+1) has suggested. I would prefer: a) User options be sent in the initial join/>. b) Unknown options are ignored. @@ -584,7 +639,7 @@

    Users generally remain in a channel for an extended period of time. In particular membership of the channel does not change when the user goes offline as happens with &xep0045;. So, leaving the channel is a permanent action for a user across all clients, not just a matter of telling the channel that the user is not currently available or for a single client. In order to leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's client will remove the channel from the user's roster.

    @@ -631,7 +686,7 @@

    @@ -646,7 +701,7 @@ @@ -663,7 +718,7 @@

    @@ -677,7 +732,7 @@ a <register/> command to the service.

    @@ -693,7 +748,7 @@ thirdwitch @@ -704,7 +759,7 @@ @@ -739,7 +794,8 @@ dnd Making a Brew ]]> -

    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.

    +

    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.

    Harpier cries: 'tis time, 'tis time. ]]> -

    The message comes from the channel as a standard groupchat message, compatible with MUC.

    +

    The message comes from the channel as a standard groupchat message, compatible with MUC. Messages are sent directly and do not use the MIX Proxy.

    AUTHOR NOTE AND QUESTION: Message id coming back is different in example. This is because the reflected message uses MAM ID, which seems helpful. However, it makes it harder for sender to correlate reflections. Need to be explicit as to compliant behaviour. Input as to whether the ID should change is solicited. A more complex option would be to include both IDs in some way.

    - AUTHOR'S NOTE: Define new protocol to support this and add example. + AUTHOR'S NOTE: Define new protocol to support this and add example.

    @@ -846,7 +902,7 @@
  • The channel member sends the invitation to the invitee.
  • The invitee uses the invitation to construct a request to join the channel.
    • -

    AUTHOR'S NOTES AND QUESTION: To be expanded considerably and perhaps modified based on the following: Dave Cridland notes: +

    AUTHOR'S NOTES AND QUESTION: Need to consider including declines. To be expanded considerably and perhaps modified based on the following: Dave Cridland notes: > There are three actors - the Member (who is the inviter), the Invitee, and > the Channel. > @@ -1119,7 +1175,14 @@

    The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID.

    - + +

    + Where a client supports MUC and MIX and has determined that for a channel that the server also supports a MUC room, the client has a choice as to which type of invite to send. This SHOULD be done by determining if the client support MIX using the mechanism specified in + Discovering Client MIX Capability. If the client supports MIX a MIX invite SHOULD be sent. + +

    + +     @@ -1182,7 +1245,7 @@

    TBD.

    -

    Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, and Matthew Wild.

    +

    Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Matthew Wild and one anonymous reviewer.