From df9908b6a5d04e1d4391f33e48df56c87ee905ff Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Sun, 29 Apr 2018 11:52:39 +0100 Subject: [PATCH 01/16] Start 0.9.7 revision and update Acknowledgements --- xep-0369.xml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/xep-0369.xml b/xep-0369.xml index 473de57a..d831feae 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -36,6 +36,14 @@ &ksmithisode; &skille; &stpeter; + + 0.9.7 + 2018-05-nn + sek +

+ +

+ 0.9.6 2018-03-18 @@ -2801,7 +2809,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

Thanks to the following who have made contributions: Dave Cridland, Tarun Gupta, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Jonas Wielicki, Matthew Wild and one anonymous reviewer.

+

Thanks to the following who have made contributions: Dave Cridland, Tarun Gupta, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Manuel Rubio, Florian Schmaus, Lance Stout, Sam Whited, Jonas Wielicki, Matthew Wild and one anonymous reviewer.

 From 502155215f72f126828965c861f91745a39a1338 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Mon, 30 Apr 2018 10:23:03 +0100 Subject: [PATCH 02/16] Clarify Owner/Administrator separation from participants and descriptions of channel roles; Clarify Owner handling on channel join; New default for configuration nodes present; Clarify configuration Last Change Made By; --- xep-0369.xml | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index d831feae..c38dd6da 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -41,7 +41,10 @@ 2018-05-nn sek

- + Clarify Owner/Administrator separation from participants and descriptions of channel roles; + Clarify Owner handling on channel join; + New default for configuration nodes present; + Clarify configuration Last Change Made By;

@@ -535,7 +538,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa AnyoneAny user, including users in the banned node.

- There MUST always be at least one Owner for a Channel. Owners, Administrators, Participants, and Allowed are optional and do not need to be set. Where no owner is explicitly set, it is anticipated that a server administrator will have owner rights. 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. + 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.

@@ -692,7 +696,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa 'Owner'Bare JIDs with Owner rights as defined in ACL node. When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value.jid-multi-- 'Administrator'Bare JIDs with Administrator rights.jid-multi-- 'End of Life'The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent.text-single-- - 'Nodes Present'Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.list-multi'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap-visible'; 'avatar'- + 'Nodes Present'Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.list-multi'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap-visible'; 'avatar''participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap-visible'; 'avatar' 'Messages Node Subscription'Controls who can subscribe to messages node.list-single'participants'; 'allowed'; 'anyone''participants' 'Presence Node Subscription'Controls who can subscribe to presence node.list-single'participants'; 'allowed'; 'anyone''participants' 'Participants Node Subscription'Controls who can subscribe to participants node.list-single'participants'; 'allowed'; 'anyone'; 'nobody'; 'admins'; 'owners''participants' @@ -2116,7 +2120,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

- The client MAY also include parameters in &xep0004; format as part of channel creation. If the client wishes to inspect configuration, channel administration procedures SHOULD be used. + The client MAY also include parameters in &xep0004; format as part of channel creation to set parameters in the configuration node. Note that any non-default values in the information node MUST be made as a separate change after the channel is created. If the client wishes to inspect configuration, channel administration procedures SHOULD be used. +

+

+ When a channel is created with default parameters, the Owner in the configuration is set to the JID that creates the channel. Where parameters are included, the Owner or Owners MUST be specified explicitly. If an owner is specified that is not the JID creating the channel, the owner is recommended to verify that this user accepts the responsibility of being an owner of this channel. Protocol to support this verification may be specified in a future XEP. Note that the 'Last Change Made By' in configuration node MUST be set to the JID that creates the channel.

-

Channel owners are allowed to modify the channel configuration. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the configuration node. Other clients MAY be authorized to use this command to see the channel configuration, but only owners MAY update the configuration. The values in the form show current values, which MAY be defaults or MAY have been explicitly set. The following example shows a short form returned to illustrate the syntax. A typical configuration form will be much larger with many fields. Modifying channel configuration is done directly by a client. +

Channel owners are allowed to modify the channel configuration. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the configuration node. Other clients MAY be authorized to use this command to see the channel configuration, but only owners MAY update the configuration. The values in the form show current values, which MAY be defaults or MAY have been explicitly set. The following example shows a short form returned to illustrate the syntax. A typical configuration form will be much larger with many fields. Modifying channel configuration is done directly by a client. Note that an Owner MUST be specified. When the configuration node is modified, the server MUST set the 'Last Change Made By' attribute to the JID of the user making the change.

Date: Mon, 30 Apr 2018 12:57:57 +0100 Subject: [PATCH 03/16] Clarify Mandatory Presence; --- xep-0369.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xep-0369.xml b/xep-0369.xml index c38dd6da..1ba8cac9 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -45,6 +45,7 @@ Clarify Owner handling on channel join; New default for configuration nodes present; Clarify configuration Last Change Made By; + Clarify Mandatory Presence;

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

- 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. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza using a <presence/> element qualified by the 'jabber:client' namespace. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list. + 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 the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza using a <presence/> element qualified by the 'jabber:client' namespace. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.

From 8b82aac23937659126798005cdabe44059634085 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 4 May 2018 07:51:57 +0100 Subject: [PATCH 04/16] Editorial --- xep-0369.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0369.xml b/xep-0369.xml index 1ba8cac9..38cce33d 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -605,7 +605,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

- This node MAY be subscribed to by users and this subscription MUST use 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 NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub. The Presence node is a permanent PubSub node. + This node MAY be subscribed to by users and this subscription MUST use 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.

From ffdbdd9dbda7960fa8eb6dba9bce74a2506d75a2 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 4 May 2018 07:55:03 +0100 Subject: [PATCH 05/16] Ensure all MAM URNs are current version --- xep-0369.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 38cce33d..676770c6 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -865,7 +865,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa name='A Dark Cave' type='mix'/> - + ]]> @@ -1812,7 +1812,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

- + Date: Fri, 4 May 2018 08:30:59 +0100 Subject: [PATCH 06/16] Clarification of MIX annotation of roster updates; --- xep-0369.xml | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 676770c6..99788c4f 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -38,7 +38,7 @@ &stpeter; 0.9.7 - 2018-05-nn + 2018-05-00 sek

Clarify Owner/Administrator separation from participants and descriptions of channel roles; @@ -1151,8 +1151,8 @@ 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. - 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 is sent about the MIX channel to the user. + 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.

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 described below. If the user changes the value of the preference, the server MUST modify subscription mode to reflect this. @@ -2659,7 +2659,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]> - +

+ Once a client has made an IQ request to return additional MIX information, the server MUST return this information on all subsequent roster updates that are sent by the server to the client. The server MUST NOT send additional MIX information when this has not been explicitly requested. It is anticipated that a client will fetch the roster after connection has been established and will set it's preference for this MIX capability information at that time. +

From 3a1b36be1caba503c19d16212ab2a4123b920e7e Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 4 May 2018 08:47:47 +0100 Subject: [PATCH 07/16] Correct errors in Example 37 --- xep-0369.xml | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 99788c4f..20067ac6 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -46,6 +46,9 @@ New default for configuration nodes present; Clarify configuration Last Change Made By; Clarify Mandatory Presence; + Clarification of MIX annotation of roster updates; + +

@@ -1384,8 +1387,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa - - + + + + @@ -1393,8 +1398,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa - - + + + + From 658ae8500a7eb44cac39b3c0603a3bd83e5db818 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 4 May 2018 09:11:09 +0100 Subject: [PATCH 08/16] Improve example indentation --- xep-0369.xml | 210 +++++++++++++++++++++++++-------------------------- 1 file changed, 105 insertions(+), 105 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 20067ac6..86cf1353 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -920,22 +920,22 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - - - - urn:xmpp:mix:1 - - - Witches Coven - - - A location not far from the blasted heath where - the three witches meet - - - greymalkin@shakespeare.example - - + + + + urn:xmpp:mix:1 + + + Witches Coven + + + A location not far from the blasted heath where + the three witches meet + + + greymalkin@shakespeare.example + + @@ -961,18 +961,18 @@ This approach enables flexible support of multiple clients for a MIX channel pa to='hag66@shakespeare.example/UUID-c8y/1573' type='result'> - - - - thirdwitch - - - - - top witch - - - + + + + thirdwitch + + + + + top witch + + + @@ -1226,19 +1226,19 @@ This approach enables flexible support of multiple clients for a MIX channel pa - - urn:xmpp:mix:1 - - - never - - - allow - - - block - - + + urn:xmpp:mix:1 + + + never + + + allow + + + block + + ]]> @@ -1257,23 +1257,23 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - - urn:xmpp:mix:1 - - - - - - - - - - - + + urn:xmpp:mix:1 + + + + + + + + + + + ]]> @@ -1606,9 +1606,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa to='coven@mix.shakespeare.example' type='get'> - - - + + + @@ -1617,13 +1617,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa to='hag66@shakespeare.example/UUID-c8y/1573' type='result'> - - - - hecate@mix.shakespeare.example - - - + + + + hecate@mix.shakespeare.example + + + ]]> @@ -1639,35 +1639,35 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='kl2fax27' to='coven@mix.shakespeare.example' type='set'> - - - - urn:xmpp:mam:2 - - - 123456#coven@mix.shakespeare.example - - - + + + urn:xmpp:mam:2 + + + 123456#coven@mix.shakespeare.example + + + - - - - - - hecate@mix.shakespeare.example - - - - - + + + + + + hecate@mix.shakespeare.example + + + + + @@ -1776,12 +1776,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa to='hag66@shakespeare.example' id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> - Harpier cries: 'tis time, 'tis time. - - thirdwitch - 123456#coven@mix.shakespeare.example - 92vax143g - + Harpier cries: 'tis time, 'tis time. + + thirdwitch + 123456#coven@mix.shakespeare.example + 92vax143g + ]]> @@ -1870,12 +1870,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa to='hag66@shakespeare.example/UUID-h5z/0253' type='result'> - - hag66@shakespeare.example - cat@shakespeare.example - coven@mix.shakespeare.example - ABCDEF - + + hag66@shakespeare.example + cat@shakespeare.example + coven@mix.shakespeare.example + ABCDEF + ]]> @@ -1928,10 +1928,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa Declined - hag66@shakespeare.example - cat@shakespeare.example - coven@mix.shakespeare.example - ABCDEF + hag66@shakespeare.example + cat@shakespeare.example + coven@mix.shakespeare.example + ABCDEF From 95500aeef95807ffeed1a8e895ba43fa7a747edd Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 4 May 2018 09:38:42 +0100 Subject: [PATCH 09/16] Flag that section 6.3 (Ensuring Message Delivery) needs review; --- xep-0369.xml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 86cf1353..29a0ecea 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -47,7 +47,7 @@ Clarify configuration Last Change Made By; Clarify Mandatory Presence; Clarification of MIX annotation of roster updates; - + Flag that section 6.3 (Ensuring Message Delivery) needs review;

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

- A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a <retract> element qualified by the 'urn:xmpp:mix:1' namespace. A retract messages MUST NOT have a body. The <retract> element MUST include an <id> attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and it's retraction shown in the following example. + A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a <retract> element qualified by the 'urn:xmpp:mix:1' namespace. A retract messages MUST NOT have a body. The <retract> element MUST include an 'id' attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and it's retraction shown in the following example.

    -
  1. The inviter checks with disco that the invitee supports MIX.
    2. +
  2. The inviter checks using capability discovery that the invitee supports MIX.
  3. The channel inviter sends to the channel requesting an invite for the invitee.
  4. The channel sends an invitation to the inviter.
  5. The inviter sends the invitation to the invitee.
    6. @@ -2028,6 +2028,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    +

    + AUTHOR NOTE (SEK): This section has issues and needs detailed review. Author action will be taken. +

    It is important that messages are all transferred from the MIX channel to the server associated with the each channel participant. Transfer between servers will typically happen quickly and &xep0198; will deal with short connection failures between servers. Longer connection failures could lead to message loss. This would lead to online users (who remain connected to their servers) missing messages, and to messages being missed out of the user archive. This section describes how MIX addresses this.

    From 26cac6d2ce7f30b566565770b4ae753207a096c5 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 4 May 2018 10:01:44 +0100 Subject: [PATCH 10/16] Editorial --- xep-0369.xml | 140 ++++++++++++++++++++++++++++----------------------- 1 file changed, 77 insertions(+), 63 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 29a0ecea..529a9a68 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -1130,7 +1130,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa At the same time the participant MUST be added to the JID Map node, to map from proxy JID to real JID. For a JID Maybe Visible channel, the participant MUST be added to the JID Maybe Visible Map node. The value in this node MUST reflect the user's visibility preference for the channel and MUST be updated to reflect any changes to this preference.

    - A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/$gt; child element of <iq/> element. The <update-subscription/$gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/$gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification. + A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/> child element of <iq/> element. The <update-subscription/> element is qualified by the 'urn:xmpp:mix:1' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/> element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.

    - It can also be useful to share some or all of the messages from the 1:1 discussion into the new channel. The mechanism to do this is to forward messages to be shared in the MUC using &xep0297;. A body SHOULD NOT be used in the outer message. - Sharing history is optional. If history is shared, it MUST be done by the user creating the channel before the other user is invited. Any other use of forwarded messages MUST be treated as a member of the MUC forwarding a message to the channel and MUST NOT be treated as history sharing. + It can also be useful to share some or all of the messages from the 1:1 discussion into the new channel. The mechanism to do this is to forward messages to be shared to the channel using &xep0297;. A body SHOULD NOT be used in the outer message. + Sharing history is optional. If history is shared, it MUST be done by the user creating the channel before the other user is invited. Any other use of forwarded messages MUST be treated as a channel participant forwarding a message to the channel and MUST NOT be treated as history sharing.

    ]]>

    - There are a number of security considerations with use of MUC history. There may be sensitive information in the 1:1 MUC 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 MUC has potential to inject history messages which were not part of the history. It is recommended that the second user joining the MUC 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.

    @@ -2271,23 +2271,25 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - - + + + urn:xmpp:mix:1 - - Information Node Modification - - Witches Coven - - - - + + Information Node Modification + + Witches Coven + + + + + @@ -2300,21 +2302,25 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='set'> - - - urn:xmpp:mix:1 - - - Witches Coven - - - A location not far from the blasted heath where + + + + + urn:xmpp:mix:1 + + + Witches Coven + + + A location not far from the blasted heath where the three witches meet - - - greymalkin@shakespeare.example - - + + + greymalkin@shakespeare.example + + + + @@ -2325,7 +2331,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - + + + @@ -2350,15 +2358,17 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - - - urn:xmpp:mix:1 - - Configuration Node Modification - - + + + + urn:xmpp:mix:1 + + Configuration Node Modification + + + @@ -2371,24 +2381,28 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='set'> - - - urn:xmpp:mix:1 - - - hecate@shakespeare.example - greymalkin@shakespeare.example - - - allowed - - - jid-mandatory-visible - - - true - - + + + + + urn:xmpp:mix:1 + + + hecate@shakespeare.example + greymalkin@shakespeare.example + + + allowed + + + jid-mandatory-visible + + + true + + + + @@ -2504,7 +2518,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa Messages from a MIX channel will usually go to 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 but 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 simply 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 dropped.

    - 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 participant's server MUST NOT make any other modifications to each message. The following example, repeated from earlier, 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 earlier, shows a message distributed by a MIX channel and directed to the participant’s server with the participant's bare JID.

    Date: Fri, 4 May 2018 11:05:27 +0100 Subject: [PATCH 11/16] Add MIX Channels in Roster Section; --- xep-0369.xml | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xep-0369.xml b/xep-0369.xml index 529a9a68..5b6481be 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -48,7 +48,7 @@ Clarify Mandatory Presence; Clarification of MIX annotation of roster updates; Flag that section 6.3 (Ensuring Message Delivery) needs review; - + Add MIX Channels in Roster Section;

    @@ -420,6 +420,18 @@

    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 messages are archived by both the MIX channel and the user's server, so that clients can generally use their local MAM archiver. 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.

     + + +

    + When a user joins a MIX channel, the channel is included in the user's roster. 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. +
    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. +
      3. +
    +

    A MIX channel does not send messages and presence directly to the MIX client of a channel participant, but addresses them to the 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. From 180111a7f52ac08c6fb180d03fbeb46ab0788673 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 4 May 2018 12:00:02 +0100 Subject: [PATCH 12/16] Add Proxy JID Architecture Section; --- xep-0369.xml | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/xep-0369.xml b/xep-0369.xml index 5b6481be..480e1ec9 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -49,6 +49,7 @@ Clarification of MIX annotation of roster updates; Flag that section 6.3 (Ensuring Message Delivery) needs review; Add MIX Channels in Roster Section; + Add Proxy JID Architecture Section;

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

    MIX channels have three modes controlling JID visibility:

    @@ -499,6 +503,27 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    The default value is 'Prefer Hidden'.

    +     + + +

    + In order to address requirement 7 (a mechanism of JID harvesting), the JID visibility modes of the previous section are defined. MUC achieves this 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. This mapping is used for all channels, as it means that all channels have the same logic and it is straightforward to switch between JID visible and JID hidden channels. + MIX also standardizes the mechanism for mapping between proxy JID and the participant's real JID, so that this can be used by a MIX client. Note that a MUC implementation will need a similar mapping mechanism, but this mechanism is not standardized. MIX maintains three mappings as PubSub nodes to support the necessary mappings: +

    + +
      +
    1. Participants. This is a list of proxy JIDs of users who have joined the channel. This list is visible to all channel participants. It MAY contain a Nick for each participant. This enables a MIX client to provide a user friendly display of each participant.
      2. +
    2. JID Map. This contains a mapping of each participant’s real JID with the associated proxy JID. It is used by the MIX channel. For JID Visible channels, it is also accessible to all channel participants, who may use it to display the real JID of each participant.
      3. +
    3. JIMD Maybe Visible Map. This is used for JID Maybe Visible channels. It contains a mapping from the participant’s real JID with the associated proxy JID, for participants that have elected to share their JID. This enables channel participants to access those JIDs that are shared in a JID Maybe Visible channel.
      4. +
    +     + + + + + + +

    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 with the name of the channel 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'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. 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.

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

    The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then 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.

    +     +

    MIX defines a number standard nodes are as follows. Note that all nodes are OPTIONAL and that not every channel will necessarily use each node:

    From b9415be939a9a853fd7e9d681ee8be75a9561875 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Wed, 9 May 2018 09:37:09 +0100 Subject: [PATCH 13/16] Replace contents of section 6.3 (Ensuring Message Delivery) with reference to future XEP; --- xep-0369.xml | 26 ++++---------------------- 1 file changed, 4 insertions(+), 22 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 480e1ec9..4e00310f 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -47,7 +47,7 @@ Clarify configuration Last Change Made By; Clarify Mandatory Presence; Clarification of MIX annotation of roster updates; - Flag that section 6.3 (Ensuring Message Delivery) needs review; + Replace contents of section 6.3 (Ensuring Message Delivery) with reference to future XEP; Add MIX Channels in Roster Section; Add Proxy JID Architecture Section;

    @@ -2068,30 +2068,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - AUTHOR NOTE (SEK): This section has issues and needs detailed review. Author action will be taken. + It is important that messages are all transferred from the MIX channel to the server associated with the each channel participant. Transfer between servers will typically happen quickly and &xep0198; will deal with short connection failures between servers. Longer connection failures could lead to message loss. This would lead to online users (who remain connected to their servers) missing messages, and to messages being missed out of the user archive.

    - It is important that messages are all transferred from the MIX channel to the server associated with the each channel participant. Transfer between servers will typically happen quickly and &xep0198; will deal with short connection failures between servers. Longer connection failures could lead to message loss. This would lead to online users (who remain connected to their servers) missing messages, and to messages being missed out of the user archive. This section describes how MIX addresses this. + To avoid missing messages, use is made of "NEW XEP - TO BE WRITTEN".

    -

    - When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a <marker/> child element of an <iq/> element. The <marker/> element is qualified by the 'urn:xmpp:mix:1' namespace. -

    - - - - - - - - -]]> +     From 4e4b27da7ed61776656c2748a8833a1c71359b50 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Wed, 9 May 2018 14:24:24 +0100 Subject: [PATCH 14/16] Add MUC Comparison Introduction Section; --- xep-0369.xml | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/xep-0369.xml b/xep-0369.xml index 4e00310f..05a746f5 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -50,6 +50,7 @@ Replace contents of section 6.3 (Ensuring Message Delivery) with reference to future XEP; Add MIX Channels in Roster Section; Add Proxy JID Architecture Section; + Add MUC Comparison Introduction Section;

    @@ -387,6 +388,39 @@ + +

    + This section is written as an introduction to MIX for those with detailed knowledge of &xep0045;, to summarize key differences and some rationale for the differences. For those unfamiliar with MUC, this section should be ignored. +

    +

    + In MUC, a client joins a MUC room. After this, the client is sent history information, presences, and messages until the client leaves the room by going offline. Key MIX features as summarized below: +

    +
      +
    1. MIX has "channels", which are equivalent to MUC rooms.
      2. + +
    2. MIX separates out various services, in particular messages and presence. A MUC channel is implemented as a set of PubSub nodes, and a user (not client) can subscribe to a set of nodes. This control means that users can subscribe to presence and/or messages, which gives useful flexibility. This addresses requirements 3 and 5. Subscribing to message and presence nodes gives a service broadly equivalent to MUC.
      3. + +
    3. Messages and presence sent by a MIX channel use the same formats as MUC and do not use PubSub encodings.
      4. + +
    4. Channels do not have a "subject". This MUC capability is not supported by core MIX.
      5. + +
    5. Users join MIX channels for an extended period and participation is not impacted by clients going online and offline (requirement 1). This means that a MIX client uses channel subscriptions as negotiated by the MIX user.
      6. + +
    6. MIX messages and presence are always sent and are addressed to the user (bare JID). This addressing is a consequence of users (not clients) being the participants in a MIX channel; It is a key difference between MUC and MIX. This addressing change means that the user's server needs to have MIX-specific behaviour to correctly distribute arriving messages and presence appropriately to MIX clients; there may be zero or more online clients that support MIX. This server behaviour is specified by MIX.
      7. + +
    7. MIX messages are archived using MAM on the user's server. This enables flexible access to channel history, independent of the MIX channel server.
      8. + +
    8. A user's roster contains the MIX channels to which the user is subscribed. A client can use a MIX roster extension to determine which MIX channels the user is subscribed to. When a client comes online, this will lead to directed presence for the client to be sent to each MIX channel. A MIX channel can then share the user's presence with channel participants that have subscribed to the presence. The MIX channel will also return to the client a full list of presence information for the channel. This means that when a client comes online, it will receive presence updates for the participants in all subscribed MIX channels.
      9. + +
    9. In MIX, a Nick belongs to the user and not to each client.
      10. + +
    10. + MUC semi-anonymous rooms are achieved by sharing on the Nick with room members. MIX provides a similar capability to address requirement 7, which is that channels have "JID Hidden" and "JID Visible" options. A mechanism is provided that is common for all channels, so that operation flow is the same for all channels and it is easy to switch between JID Visible and JID Hidden. Each channel participant has an anonymized proxy JID that references the user in the channel. There is a PubSub mechanism to map proxy JID to Nick which allows clients to look up (current) Nick for a proxy JID. There is also a PubSub mechanism to map from proxy JIDs to real JIDs. This mechanism is used by the channel to map JIDs and may be used by clients in JID Visible channels to determine the JID. +
      11. + +
    +     +

    MIX will enable a wide range of auxiliary services. The goal of the MIX specification is to set out the core capabilities needed for MIX. It is anticipated that additional XEPs will be written to extend the core MIX, and the core MIX specification notes some areas where this may happen. This approach will avoid the core MIX specification becoming unduly large. Profiles referencing sets of related MIX XEPs may be developed in the future. From 651b659a42bbd5e319bc3275eb34ba5b80f96d88 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Wed, 9 May 2018 14:26:45 +0100 Subject: [PATCH 15/16] Add requirement to clarify MIX is intended for non-human use; --- xep-0369.xml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xep-0369.xml b/xep-0369.xml index 05a746f5..fe586261 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -51,6 +51,7 @@ Add MIX Channels in Roster Section; Add Proxy JID Architecture Section; Add MUC Comparison Introduction Section; + Add requirement to clarify MIX is intended for non-human use;

    @@ -384,6 +385,7 @@
  6. Enable sharing of messages on a channel without requiring sharing of presence.
  7. Enable sharing of presence without requiring message sending.
  8. (Desirable) Make it easier to reduce duplicate traffic.
    9. +
  9. MIX should be suitable for use by humans and as a building block for other clients.
From f103ed804734d1383fd46c17554021d2a8966cb2 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Wed, 9 May 2018 14:42:46 +0100 Subject: [PATCH 16/16] Set date and version number --- xep-0369.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index fe586261..ece0c3d5 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -37,8 +37,8 @@ &skille; &stpeter; - 0.9.7 - 2018-05-00 + 0.10.0 + 2018-05-10 sek

Clarify Owner/Administrator separation from participants and descriptions of channel roles;