diff --git a/xep-0369.xml b/xep-0369.xml index d1562867..cb89a2ac 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -100,7 +100,9 @@ - +

The following concepts underlie the design of MIX.

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

    MIX is based upon domains providing a MIX service, such as 'mix.shakespeare.example'. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; domain. Like MUC, there is no requirement on the naming of these domains; the label 'mix' and the fact that it is a subdomain of a 'shakespeare.example' service are purely for example.

    Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed using a bare JID by other XMPP entities, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, MIX uses standard presence and groupchat messages to provide an interface to the MIX service that does not expose PubSub protocol for many of the more common functions. @@ -146,11 +149,18 @@ 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.

    - 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) will be discarded if all clients are offline. Offline messages are not used with MIX. + 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.

    - Online clients are handled use &xep0376;. - The model is that the server will know which of the user's clients are interested in MIX messages, possibly filtered by MIX channel, and will deliver messages appropriately to these clients. MIX will send messages to the user's server addressed with the bare JID of the user. The user's server will then deliver messages to the user's clients, in a manner that is transparent to the MIX server. The same approach is used for sending presence updates to the user, noting that presence information is distributed by a channel to the bare JID of subscribers and then the user's server will distribute to clients as appropriate. + 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. +

    +     + + + +

    + It may be desirable in some situtations 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.

    @@ -386,22 +396,14 @@ name='Shakespearean Chat Service' type='text'/> - - - urn:xmpp:mix:0#serviceinfo - - - chat.shakespeare.example - ]]>

    The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. - If the MIX service is mirrored to a MUC service for backwards-compatibility, this SHOULD be signaled by the inclusion of field with var='muc-mirror', the value of which is the mirrored MUC domain's JID. Where a MIX server supports MIX channels as &xep0045; rooms, the domain used for MUC may be different to the MIX domain or it MAY be the same.

    -

    Note that the MIX service doesn't advertise support for &xep0313;, nor is support for generic &xep0060; advertised.

    +

    +

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

    @@ -420,7 +422,7 @@ ]]> -

    The channel MUST return its identity and the features it supports:

    +

    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.

    +     ]]> @@ -1008,6 +1011,104 @@     + +

    + MIX is specified as a service that can be used independent of MUC and a MIX service may be implemented without MUC. If both MIX and MUC are implemented, three approaches are noted. +

    +
      +
    1. Entirely separate MIX and MUC implementation, with MIX and MUC using separate domains and MIX channels being completely separate from MUC rooms.
      2. + +
    2. Fully integrated MIX and MUC implementation, with MIX and MUC sharing a single domain and rooms/channels equivalent.
      3. + +
    3. Partially integrated MIX and MUC implementation, with MIX and MUC using separate domains, but rooms/channel are common. This means that each MIX channel will have MUC room of the same name and common membership.
      4. +
    + +

    The fully integrated approach would be transparent to clients. Disco of a room or channel would show support for both MUC and MIX, which would enable a client to choose whether to use MUC or MIX. The following example shows how a MIX service that also supported MUC would respond:

    + + + + + + + + + urn:xmpp:mix:0#serviceinfo + + + + +]]> + + +

    For the partially integrated service, it will be useful for clients that support both MIX and MUC to be able to determine that the server supports both protocols. For a MIX client, it will be useful to know the MUC service, so that this information can be shared with a MUC client invitation. This information is provided by the initial service discovery:

    + + + + + + + + + urn:xmpp:mix:0#serviceinfo + + + chat.shakespeare.example + + + + +]]> + +

    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='muc-mirror' is the value of which is the mirrored MUC domain's JID.

    + +

    Where a client supporting both MIX and MUC is given a reference to a MUC room, it is desirable that the client can determine the MIX channel and join using MIX. This is achieved by an equivalent extension to MUC service discover.

    + + + + + + + + urn:xmpp:mix:0#serviceinfo + + + mix.shakespeare.example + + + + +]]> + +

    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.

    + + + +