From dc913b855c07fa4362e1de0d190e5ef69c7a3815 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Tue, 22 May 2018 15:20:12 +0200 Subject: [PATCH] Inter-link MIX XEPs --- xep-0369.xml | 12 ++++----- xep-0403.xml | 70 ++++++++++++++++++++++++++-------------------------- xep-0404.xml | 22 ++++++++--------- xep-0405.xml | 56 ++++++++++++++++++++--------------------- xep-0406.xml | 14 +++++------ xep-0407.xml | 12 ++++----- xep-0408.xml | 28 ++++++++++----------- xep.ent | 7 ++++++ 8 files changed, 114 insertions(+), 107 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 4b94f423..0e90bfb0 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -408,12 +408,12 @@
  1. 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.
    2. -
  2. MIX-PRESENCE. XEP-0403. This optional specification adds the ability for MIX online clients to share presence, so that this can be seen by other MIX clients.
    3. -
  3. MIX-PAM. XEP-0405. This mandatory specification defines how a server supporting MIX clients behaves, to support servers implementing MIX-CORE and MIX-PRESENCE.
    4. -
  4. MIX-ADMIN. XEP-0406. This specifies MIX configuration and administration of MIX.
    5. -
  5. MIX-ANON. XEP-0404. This specifies a mechanism to hide real JIDs from MIX clients and related privacy controls.
    6. -
  6. MIX-MISC. XEP-0407. This specifies a number of small MIX capabilities which are useful but do not need to be a part of MIX-CORE.
    7. -
  7. MIX-MUC. XEP-0408. This defines how MIX and MUC can be used together.
    8. +
  8. 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.
    9. +
  9. MIX-PAM. &xep0405;. This mandatory specification defines how a server supporting MIX clients behaves, to support servers implementing MIX-CORE and MIX-PRESENCE.
    10. +
  10. MIX-ADMIN. &xep0406;. This specifies MIX configuration and administration of MIX.
    11. +
  11. MIX-ANON. &xep0404;. This specifies a mechanism to hide real JIDs from MIX clients and related privacy controls.
    12. +
  12. MIX-MISC. &xep0407;. This specifies a number of small MIX capabilities which are useful but do not need to be a part of MIX-CORE.
    13. +
  13. MIX-MUC. &xep0408;. This defines how MIX and MUC can be used together.
  14. RELIABLE-DELIVERY. MIX-CORE needs messages to be distributed without loss. This specification is important for MIX, but may be useful in other places.
diff --git a/xep-0403.xml b/xep-0403.xml index 4800240a..5070bdc8 100644 --- a/xep-0403.xml +++ b/xep-0403.xml @@ -48,7 +48,7 @@ -

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

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.

@@ -61,8 +61,8 @@
  • The mechanism must work cleanly for participants with multiple clients.
  • Standard presence messages must be used to share presence.
  • Nick changes should be visible as changes (and not as a new user).
    • -
  • Where MIX-ANON is not used, participants must be able to directly contact other participants.
    • - +
  • Where &xep0404; is not used, participants must be able to directly contact other participants.
    • + @@ -75,35 +75,35 @@ 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.

    - 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 MIX-PAM. + 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;.

    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:

      -
    1. The bare proxy JID of the client, as specified in MIX-CORE. 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.
      2. -
    2. The resource taken from the client’s full JID, except when MIX-ANON is used, when the resource is hidden.
      3. +
    3. 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.
      4. +
    4. The resource taken from the client’s full JID, except when &xep0404; is used, when the resource is hidden.

    - 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 MIX-ANON is used to hide JIDs, only the Nick can be derived. + 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.

    - Presence updates are distributed by a channel to the bare JID of each participant and then the subscriber's server will distribute to each of the participant's currently online clients following the rules set out in MIX-PAM. + Presence updates are distributed by a channel to the bare JID of each participant and then the subscriber's server will distribute to each of the participant's currently online clients following the rules set out in &xep0405;.

    -

    - When a user joins a MIX channel, the channel MUST be added to the user's roster, as specified in MIX-PAM. There are two reasons for this. +

    + When a user joins a MIX channel, the channel MUST be added to the user's roster, as specified in &xep0405;. There are two reasons for this.

    1. It enables a client to determine which channels the user has joined and so may expect messages and/or presence updates from (dependent on what the user has subscribed to).
    2. - When the user has chosen to share presence with the channel, it enables this to happen using standard presence mechanisms. This avoids the need for MIX-specific mechanisms for clients to update presence on a channel. When a client comes online, presence information will be sent to each MIX channel that the user participates in. This will update other channel participants. It will also lead to a presence update for each MIX channel being sent to the client. So a user will receive channel presence information as the user comes online, in contrast to being subsequent to a MUC Join. + When the user has chosen to share presence with the channel, it enables this to happen using standard presence mechanisms. This avoids the need for MIX-specific mechanisms for clients to update presence on a channel. When a client comes online, presence information will be sent to each MIX channel that the user participates in. This will update other channel participants. It will also lead to a presence update for each MIX channel being sent to the client. So a user will receive channel presence information as the user comes online, in contrast to being subsequent to a MUC Join.
    @@ -126,11 +126,11 @@

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

    - 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 full JID 'hecate@shakespeare.example/UUID-x4r/2491'.

    @@ -163,8 +163,8 @@

    -A user MAY share presence information with the channel, for one or more online clients. The channel is entered by the user's server into the user's roster when the user subscribes to the channel as specified in MIX-PAM. Where a user shares presence information with a channel, the subscription is configured with one way presence, which will cause all presence changes for the client to be sent to the channel. - When an XMPP client comes online or changes presence status, this will be communicated by the user to the user's server using broadcast presence. The user's XMPP server is then responsible to share this presence information to each entry in the roster and in particular to each MIX channel in the roster. +A user MAY share presence information with the channel, for one or more online clients. The channel is entered by the user's server into the user's roster when the user subscribes to the channel as specified in &xep0405;. Where a user shares presence information with a channel, the subscription is configured with one way presence, which will cause all presence changes for the client to be sent to the channel. + When an XMPP client comes online or changes presence status, this will be communicated by the user to the user's server using broadcast presence. The user's XMPP server is then responsible to share this presence information to each entry in the roster and in particular to each MIX channel in the roster.

    The MIX channel will update the "urn:xmpp:mix:nodes:presence" node with any change of status and the updated presence information and then share this updated presence with users subscribed to this node, as described below. When the user sets an explicit status, this is used to modify the presence node in the channel. When a client being used by the user goes offline, the associated server will send presence status "unavailable" to the MIX channel, which will cause the node item for that client to be removed from the presence node. @@ -201,8 +201,8 @@ A user MAY share presence information with the channel, for one or more online c Making a Brew ]]>

    - The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence stanza. The presence change is recorded on the "urn:xmpp:mix:nodes:presence" node. - + The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence stanza. The presence change is recorded on the "urn:xmpp:mix:nodes:presence" node. +

    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. @@ -215,8 +215,8 @@ A user MAY share presence information with the channel, for one or more online c

    - MIX Clients obtain presence from their local server. This is specified in MIX-PAM. - + MIX Clients obtain presence from their local server. This is specified in &xep0405;. +

    @@ -246,49 +246,49 @@ A user MAY share presence information with the channel, for one or more online c 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.

    - - + + - +

    - The primary actions for a user leaving a channel are specified in MIX-CORE. 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. + 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.

    - + ]]> - - + +     - + - - - + + +

    For an active MIX Channel, the presence node is updated as channel participants change status and presence information is sent to the channel. When a MIX channel starts, typically when the associated MIX Service and Server start, there is a need to initialize the presence node. This is done by the XMPP server associated with the MIX channel sending out a presence probe for each channel participant, following the presence probe process specified in &rfc6121;. A presence probe MUST NOT be sent for users who have set presence preference to not sharing.

    - + -

    See considerations in MIX-CORE. +

    See considerations in &xep0369;.

    -

    See considerations in MIX-CORE.

    - +

    See considerations in &xep0369;.

    +

    When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.

    @@ -308,7 +308,7 @@ A user MAY share presence information with the channel, for one or more online c     -

    See MIX-CORE for a list of contributors to the MIX Family of specifications.

    +

    See &xep0369; for a list of contributors to the MIX Family of specifications.

     diff --git a/xep-0404.xml b/xep-0404.xml index 30783e7a..ca914c6c 100644 --- a/xep-0404.xml +++ b/xep-0404.xml @@ -48,7 +48,7 @@ -

    The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). This specification provides mechanisms to hide participant JIDs from other participants. This is needed to address privacy concerns and to prevent JID harvesting. It also addresses privacy issues, and gives participants options to control sharing of information. +

    The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). This specification provides mechanisms to hide participant JIDs from other participants. This is needed to address privacy concerns and to prevent JID harvesting. It also addresses privacy issues, and gives participants options to control sharing of information.

    @@ -64,7 +64,7 @@

    - MIX-CORE exposes participant JIDs to other participants, and so messages can always be sent directly. When JIDs are hidden this is no longer possible. + &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.

    @@ -100,7 +100,7 @@

    - 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 MIX-CORE, 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 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

    @@ -111,8 +111,8 @@

    - -This change means that the client will not be able to determine real JID of the participant using the participant node, as it can with MIX-CORE. + +This change means that the client will not be able to determine real JID of the participant using the participant node, as it can with &xep0369;.

    @@ -132,7 +132,7 @@ This change means that the client will not be able to determine real JID of the

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

    @@ -415,18 +415,18 @@ This change means that the client will not be able to determine real JID of the ]]>     - + -

    See considerations in MIX-CORE. +

    See considerations in &xep0369;.

    -

    See considerations in MIX-CORE.

    - +

    See considerations in &xep0369;.

    +     @@ -444,7 +444,7 @@ This change means that the client will not be able to determine real JID of the -

    See MIX-CORE for a list of contributors to the MIX Family of specifications.

    +

    See &xep0369; for a list of contributors to the MIX Family of specifications.

     diff --git a/xep-0405.xml b/xep-0405.xml index 184259de..a39831db 100644 --- a/xep-0405.xml +++ b/xep-0405.xml @@ -48,7 +48,7 @@ -

    The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). MIX-CORE and MIX-PRESENCE define behaviour of a MIX server supporting MIX channels. In order for a MIX system to operate correctly, the XMPP server connecting MIX clients MUST follow the rules set out in this specification to achieve correct MIX operation. This specification also sets out requirements for XMPP clients, so a MIX client MUST follow both the rules of XMPP-CORE and this specification. +

    The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). MIX-CORE and &xep0403; define behaviour of a MIX server supporting MIX channels. In order for a MIX system to operate correctly, the XMPP server connecting MIX clients MUST follow the rules set out in this specification to achieve correct MIX operation. This specification also sets out requirements for XMPP clients, so a MIX client MUST follow both the rules of XMPP-CORE and this specification.

    @@ -102,7 +102,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa Messages from a MIX channel will usually be handled by the participant's server. The only exception to this is where the MIX channel is responding directly to messages from the client. Messages and presence distributed by a MIX channel will always be sent to the participant's server and addressed to the user's bare JID. The participant's server will archive the message in MAM and send on the messages from the channel to each of the user's online clients which advertise MIX capability. If there are no such clients activated, the message is not sent to any clients.

    - 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 MIX-CORE, shows a message distributed by a MIX channel and directed to the participant’s server with the participant's bare JID. + 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.

    - - -

    A user joins a channel by sending a MIX "client-join" command from one of the user's clients, which wraps the "join" command specified in MIX-CORE. MIX-CORE specifies how the join command works, and so this specification considers only the wrapping and client actions. - The <client-join/> is a child element of <iq/> element. The <client-join/> element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being joined is specified by a 'channel' attribute in the <client-join/> element, which is used by the server to correctly address the join. The <join> is specified in MIX-CORE and is a child element of <client-join/>. + + +

    A user joins a channel by sending a MIX "client-join" command from one of the user's clients, which wraps the "join" command specified in &xep0369;. &xep0369; specifies how the join command works, and so this specification considers only the wrapping and client actions. + The <client-join/> is a child element of <iq/> element. The <client-join/> element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being joined is specified by a 'channel' attribute in the <client-join/> element, which is used by the server to correctly address the join. The <join> is specified in &xep0369; and is a child element of <client-join/>.

    - The MIX service will process this request and respond as specified by MIX-CORE. An example response taken from MIX-CORE is shown below. + The MIX service will process this request and respond as specified by &xep0369;. An example response taken from &xep0369; is shown below.

    - @@ -279,9 +279,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

    Users generally remain in a channel for an extended period of time. The process for leaving a MIX channel is specified in MIX-CORE. When a user desires to leave a channel, it will issue a client-leave request to the local server. - - The <client-leave/> is a child element of <iq/> element. The <client-leave/> element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being left is specified by a 'channel' attribute in the <client-leave/> element, which is used by the server to correctly address the join. The <leave> is specified in MIX-CORE and is a child element of <client-leave/>. +

    Users generally remain in a channel for an extended period of time. The process for leaving a MIX channel is specified in &xep0369;. When a user desires to leave a channel, it will issue a client-leave request to the local server. + + The <client-leave/> is a child element of <iq/> element. The <client-leave/> element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being left is specified by a 'channel' attribute in the <client-leave/> element, which is used by the server to correctly address the join. The <leave> is specified in &xep0369; and is a child element of <client-leave/>. This shown in the following example.

    @@ -298,7 +298,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

    - The user's server will then generate a matching leave request to the MIX channel based on this information. This example is taken from MIX-CORE. + The user's server will then generate a matching leave request to the MIX channel based on this information. This example is taken from &xep0369;.

    - The MIX channel will then process the leave and respond. The following example is taken from MIX-CORE. + The MIX channel will then process the leave and respond. The following example is taken from &xep0369;.

    - After receiving the confirmation that the user has left the MIX channel, the user's server will remove the MIX channel entry from the user's roster and follow other processing as specified below. The user's server will then notify the client with the servers response. + After receiving the confirmation that the user has left the MIX channel, the user's server will remove the MIX channel entry from the user's roster and follow other processing as specified below. The user's server will then notify the client with the servers response. This wraps the response from the server with a client-leave, with the 'from' set to the user's bare JID and the 'to' set to the client's full JID. This is illustrated below:

    @@ -348,7 +348,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - As part of the channel joining process, the user's server MUST add the MIX channel to the user's roster. This is done to share the user's presence status with the channel and channel participants subscribing to presence, when the user wishes this presence to be shared. These roster entries also enables the user's client to quickly determine which channels the user has joined. The user's server will need to record those roster entries that are associated with MIX channels in order to correctly handle MIX processing. + As part of the channel joining process, the user's server MUST add the MIX channel to the user's roster. This is done to share the user's presence status with the channel and channel participants subscribing to presence, when the user wishes this presence to be shared. These roster entries also enables the user's client to quickly determine which channels the user has joined. The user's server will need to record those roster entries that are associated with MIX channels in order to correctly handle MIX processing. This roster entry will lead to the user's server correctly sending user's presence from all the user's MIX clients to the MIX channel. Where the user wishes to share presence, the roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information about the MIX channel is sent to the user.

    @@ -358,8 +358,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - If the user does not wish to publish presence information to the channel, the user's server will add the roster entry with mode subscription=none. The roster entry will be present to record that the user has joined the channel, but it will not send presence information to the channel. The user's server MUST do this when the user has chosen Presence preference of 'not share' as specified in MIX-ANON. If the user changes the value of the preference, the server MUST modify subscription mode to reflect this. - + If the user does not wish to publish presence information to the channel, the user's server will add the roster entry with mode subscription=none. The roster entry will be present to record that the user has joined the channel, but it will not send presence information to the channel. The user's server MUST do this when the user has chosen Presence preference of 'not share' as specified in &xep0404;. If the user changes the value of the preference, the server MUST modify subscription mode to reflect this. +

    The user's server MUST remove the user's roster entry when the user leaves the channel. @@ -377,9 +377,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - - A user joins a channel over an extended period, and participation in a channel does not generally change when a user clients go online or offline. The user's participation in a channel is reflected by the user's bare JID in the participant node. When a user subscribes to presence as specified in MIX-PRESENCE, all presence messages are sent to this JID. Presence updates are sent out to subscribing participants using standard presence stanzas. - + + A user joins a channel over an extended period, and participation in a channel does not generally change when a user clients go online or offline. The user's participation in a channel is reflected by the user's bare JID in the participant node. When a user subscribes to presence as specified in &xep0403;, all presence messages are sent to this JID. Presence updates are sent out to subscribing participants using standard presence stanzas. +

    @@ -400,9 +400,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa dnd Making a Brew ]]>     - +

    - 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 MIX-CORE. + 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;.

    - A MIX channel will send out presence information to participants that subscribe to the presence node, as specified in MIX-PRESENCE. An example is shown below: + A MIX channel will send out presence information to participants that subscribe to the presence node, as specified in &xep0403;. An example is shown below:

    - The client receiving the presence can parse the proxy JID, specified in MIX-CORE 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 MIX-CORE. + 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;.

    @@ -535,14 +535,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

    See considerations in MIX-CORE. +

    See considerations in &xep0369;.

    -

    See considerations in MIX-CORE.

    - +

    See considerations in &xep0369;.

    +

    When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.

    @@ -562,7 +562,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa     -

    See MIX-CORE for a list of contributors to the MIX Family of specifications.

    +

    See &xep0369; for a list of contributors to the MIX Family of specifications.

     diff --git a/xep-0406.xml b/xep-0406.xml index 1d034e81..40024f0b 100644 --- a/xep-0406.xml +++ b/xep-0406.xml @@ -46,10 +46,10 @@ Split out from MIX 0.10.0;

    - + -

    The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). This document defines a framework for administering a MIX service, including MIX-CORE, MIX-PRESENCE and MIX-ANON. It defines MIX channel configuration in a standardized manner, to enable consistent MIX administration using standard capabilities. +

    The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). This document defines a framework for administering a MIX service, including &xep0369;, &xep0403; and &xep0404;. It defines MIX channel configuration in a standardized manner, to enable consistent MIX administration using standard capabilities.

    @@ -87,7 +87,7 @@ AnyoneAny user, including users in the banned node.

    - There MUST always be at least one Owner set for a Channel. Administrators are optional and do not need to be set. Administrators and Owners MAY be participants but are not required to be. Owners and Administrators are configured in the information node. Participants and Allowed are specified in separate nodes. + There MUST always be at least one Owner set for a Channel. Administrators are optional and do not need to be set. Administrators and Owners MAY be participants but are not required to be. Owners and Administrators are configured in the information node. Participants and Allowed are specified in separate nodes. Rights are defined in a strictly hierarchical manner following the order of this table, so that for example Owners will always have rights that Administrators have.

    @@ -441,14 +441,14 @@ -

    See considerations in MIX-CORE. +

    See considerations in &xep0369;.

    -

    See considerations in MIX-CORE.

    - +

    See considerations in &xep0369;.

    +     @@ -466,7 +466,7 @@     -

    See MIX-CORE for a list of contributors to the MIX Family of specifications.

    +

    See &xep0369; for a list of contributors to the MIX Family of specifications.

     diff --git a/xep-0407.xml b/xep-0407.xml index 9a628868..a0e8abed 100644 --- a/xep-0407.xml +++ b/xep-0407.xml @@ -67,7 +67,7 @@

    - MIX-CORE defines a framework of nodes associated with each channel, where new nodes can be added to provide new services. + &xep0369; defines a framework of nodes associated with each channel, where new nodes can be added to provide new services. Two nodes defined in this specification MAY bey used to support Avatars. These nodes and their use is defined in &xep0084;. These nodes MAY be created as part of a MIX channel, where it is desired to publish an avatar associated with the channel.

    @@ -343,7 +343,7 @@ ]]>

    - There are a number of security considerations with sharing 1:1 history in a channel. There may be sensitive information in the 1:1 history, and the user sharing this history should ensure that none of this is sensitive, prior to sharing in this way. The user creating the channel has potential to inject history messages which were not part of the history. It is recommended that the second user joining the channel to validate that the messages match the history and to take appropriate action if they do not. + There are a number of security considerations with sharing 1:1 history in a channel. There may be sensitive information in the 1:1 history, and the user sharing this history should ensure that none of this is sensitive, prior to sharing in this way. The user creating the channel has potential to inject history messages which were not part of the history. It is recommended that the second user joining the channel to validate that the messages match the history and to take appropriate action if they do not.

    @@ -352,14 +352,14 @@ -

    See considerations in MIX-CORE. +

    See considerations in &xep0369;.

    -

    See considerations in MIX-CORE.

    - +

    See considerations in &xep0369;.

    +

    When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.

    @@ -379,7 +379,7 @@     -

    See MIX-CORE for a list of contributors to the MIX Family of specifications.

    +

    See &xep0369; for a list of contributors to the MIX Family of specifications.

     diff --git a/xep-0408.xml b/xep-0408.xml index d1c0bee9..b49a5848 100644 --- a/xep-0408.xml +++ b/xep-0408.xml @@ -46,8 +46,8 @@ -

    The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). - MIX can be used independently of &xep0045; (MUC). +

    The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). + MIX can be used independently of &xep0045; (MUC).

    It may be desirable to operate a service that provides MIX and MUC together. This specification specifies three options for achieving this. @@ -67,10 +67,10 @@

  • Fully integrated MIX and MUC implementation, with MIX and MUC sharing a single domain and rooms/channels equivalent.
  • Partially integrated MIX and MUC implementation, with MIX and MUC using separate domains, but all rooms/channel are common. This means that each MIX channel will have MUC room of the same name and same participants.
    • -

    The fully integrated approach would be transparent to clients. The following example shows how a service that supports MIX and MUC in a fully integrated manner would respond following the specification of MIX-CORE:

    +

    The fully integrated approach would be transparent to clients. The following example shows how a service that supports MIX and MUC in a fully integrated manner would respond following the specification of &xep0369;:

    @@ -91,16 +91,16 @@ ]]> -

    In the fully integrated service item discovery on the MIX/MUC service determines a list of channels. The protocol used for this is the same in MUC and MIX. Discovery actions on a channel in MIX MUST use 'node=mix' attribute in the discovery which will lead to the return of MIX channel specific information, as mandated for this discovery in MIX-CORE. If is not set, MUC room specific information is returned. +

    In the fully integrated service item discovery on the MIX/MUC service determines a list of channels. The protocol used for this is the same in MUC and MIX. Discovery actions on a channel in MIX MUST use 'node=mix' attribute in the discovery which will lead to the return of MIX channel specific information, as mandated for this discovery in &xep0369;. If is not set, MUC room specific information is returned.

    -

    For the partially integrated service, MIX servers will reference the associated MUC server and MUC servers will reference the associated MIX service. This will allow a client that only support MUC or only supports MIX to find the right server if it is given a reference to the other one. For a client that supports both MUC and MIX, it will enable the client to select its preferred service. +

    For the partially integrated service, MIX servers will reference the associated MUC server and MUC servers will reference the associated MIX service. This will allow a client that only support MUC or only supports MIX to find the right server if it is given a reference to the other one. For a client that supports both MUC and MIX, it will enable the client to select its preferred service. For a MIX client, it will also be useful to know the MUC service, so that this information can be shared with a MUC client invitation. The following example shows how a MIX server identifies the associated MUC server. Note that MUC MUST NOT be advertized as a feature: - +

    @@ -133,7 +133,7 @@

    Similarly, a MUC service can advertise an associated MIX doming. The following example shows discovery of a MUC domain. Note that MIX MUST NOT be advertized as a feature

    @@ -166,7 +166,7 @@

    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 - MIX-CORE. If the client supports MIX a MIX invite SHOULD be sent. + &xep0369;. If the client supports MIX a MIX invite SHOULD be sent.

    @@ -174,14 +174,14 @@ -

    See considerations in MIX-CORE. +

    See considerations in &xep0369;.

    -

    See considerations in MIX-CORE.

    - +

    See considerations in &xep0369;.

    +

    When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.

    @@ -201,7 +201,7 @@     -

    See MIX-CORE for a list of contributors to the MIX Family of specifications.

    +

    See &xep0369; for a list of contributors to the MIX Family of specifications.

     diff --git a/xep.ent b/xep.ent index 7a47850a..95e73d8e 100644 --- a/xep.ent +++ b/xep.ent @@ -1521,3 +1521,10 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Multi-Factor Authentication with TOTP (XEP-0400) XEP-0400: Multi-Factor Authentication with TOTP <https://xmpp.org/extensions/xep-0400.html>." > Easy User Onboarding (XEP-0401) XEP-0401: Easy User Onboarding <https://xmpp.org/extensions/xep-0401.html>." > +Bookmarks 2 (This Time it's Serious) (XEP-0402) XEP-0402: Bookmarks 2 (This Time it's Serious) <https://xmpp.org/extensions/xep-0402.html>." > +Mediated Information eXchange (MIX): Presence Support. (XEP-0403) XEP-0403: Mediated Information eXchange (MIX): Presence Support. <https://xmpp.org/extensions/xep-0403.html>." > +Mediated Information eXchange (MIX): JID Hidden Channels. (XEP-0404) XEP-0404: Mediated Information eXchange (MIX): JID Hidden Channels. <https://xmpp.org/extensions/xep-0404.html>." > +Mediated Information eXchange (MIX): Participant Server Requirements (XEP-0405) XEP-0405: Mediated Information eXchange (MIX): Participant Server Requirements <https://xmpp.org/extensions/xep-0405.html>." > +Mediated Information eXchange (MIX): MIX Administration (XEP-0406) XEP-0406: Mediated Information eXchange (MIX): MIX Administration <https://xmpp.org/extensions/xep-0406.html>." > +Mediated Information eXchange (MIX): Miscellaneous Capabilities (XEP-0407) XEP-0407: Mediated Information eXchange (MIX): Miscellaneous Capabilities <https://xmpp.org/extensions/xep-0407.html>." > +Mediated Information eXchange (MIX): Co-existence with MUC (XEP-0408) XEP-0408: Mediated Information eXchange (MIX): Co-existence with MUC <https://xmpp.org/extensions/xep-0408.html>." >