- A MIX channel MAY support message retraction, where the sender of a messages or an administrator deletes a message. If this is done the original message MUST be replaced by a tombstone. The protocol to request retraction does this by a message with a <retract> element as 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. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by a message with a <retract> element as shown in the following example.
- The MIX channel will allow a user to retract a message sent by the user if the 'Allow User Message Retraction' option is configured. The MIX channel will allow a user to retract any message if the user is in the group specified by the 'Administrator Message Retraction Rights' option.
+ The MIX channel will allow a user to retract a message sent by the user if the 'Allow User Message Retraction' option is configured. The MIX channel will allow an administrative user to retract any message if the user is in the group specified by the 'Administrator Message Retraction Rights' option.
If the retraction message is accepted, it will be distributed to channel participants. This will allow retraction to happen in the MAM archive of each channel participant and to reflect the retraction in client GUI. A client receiving a retraction message SHOULD ensure that the retracted message is no longer displayed to the end user.
- When a message is retracted the original message <body> MUST be removed and MUST be replaced with a tombstone using the <retracted> element that shows the JID of user performing the retraction and the time of the retraction.
+ Two approaches to message retraction may be used. In the first approach, the retracted message is simply removed. This is appropriate where retraction is provided as a user service and the user has rights to remove messages sent from the record.
+
+
+ The second approach is to leave a tombstone, which if taken MUST be done in the following manner. This is appropriate where it is desired to leave a record of the message that was redacted.
+ With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element that shows the JID of user performing the retraction and the time of the retraction.
@@ -1423,7 +1436,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
- A user may request the vCard of a channel participant by sending a request through the channel. The request may be sent directly by the client or through a MIX Proxy. The MIX channel MAY pass this request on or may block it. In the following example, the requesting client sends a message to the anonymized bare JID of the channel participant for which the vCard is desired.
+ A user may request the vCard of a channel participant by sending a request through the channel. The request may be sent directly by the client or through a MIX Proxy. The MIX channel MAY pass this request on or may block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). Where a MIX service supports one or both of these protocols, the protocol MUST be advertized as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the anonymized bare JID of the channel participant for which the vCard is desired.
- Authorized users, typically owners and sometimes administrators, may modify the channel information. The client MAY issue a get command to obtain a form that will facilitate update of the information node. The values in the form show current values, which be defaults or may have been explicitly set. In the following example, the channel name was previously set, but other values were not.
+ Authorized users, typically owners and sometimes administrators, may modify the channel information. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the information node. The values in the form show current values, which be defaults or may have been explicitly set. In the following example, the channel name was previously set, but other values were not.
-
+
+
+
-
+
+
urn:xmpp:mix:0
@@ -1726,16 +1742,18 @@ A client creates a channel by sending a simple request to the MIX service. A c
label='Channel Administrative Contact'
var='Contact'/>
-
+
+
]]>
- Updating the information node is done using a set command of type info. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the information node item, which is the date/time of the modification.
+ Updating the information node is done using a pubsub set command. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the information node item, which is the date/time of the modification.
-
+
+
urn:xmpp:mix:0
@@ -1750,32 +1768,40 @@ A client creates a channel by sending a simple request to the MIX service. A c
greymalkin@shakespeare.lit
-
+
+
-
+
+
+ Channel owners may modify the channel configuration. The client MAY issue a get command "config" 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 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.
+ Channel owners may 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 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.
-
+
+
+
-
+
+
urn:xmpp:mix:0
@@ -1785,16 +1811,18 @@ A client creates a channel by sending a simple request to the MIX service. A c
label='Channel Administrator'
var='Administrator'/>
-
+
+
]]>
- Updating the information node is done using a set command of type config. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the configuration node item, which is the date/time of the modification.
+ Updating the information node is done using a pubsub set command. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the configuration node item, which is the date/time of the modification.
-
+
+
urn:xmpp:mix:0
@@ -1815,14 +1843,19 @@ A client creates a channel by sending a simple request to the MIX service. A c
true
-
+
+
-
+
+
+
+ This section defines behaviour of the MIX Proxy Service, so that the full MIX specification for clients and servers is set out in a single document. MIX Proxy support MUST be provided by servers used by clients that participate in MIX channels. In future, MIX Proxy specification may be moved to a separate XEP or it may be incorporated into
+ &xep0376; (PAM) which follows a model close to MIX Proxy.
+
+
+
+
+ All messages from MIX channels to users are sent to the user's MIX Proxy, which resides on the user's XMPP server. The MIX Proxy will send on these messages to each of the user's clients that has activated the MIX service. MIX provides capabilities for an online client to activate and de-activate MIX for that client. A client may activate MIX for all the user's channels or for a selected list. This will enable a mobile client to choose to receive only messages from selected MIX channels. Activation uses an IQ set with an <activate> element to instruct the MIX proxy to activate the client. The server responds with a result to confirm activation. The client may include one or more <channel> elements, to identify an explicit list of channels that are activated for the client. If mo channels are specified, activation is for all channels where the user is a participant. A client supporting MIX will typically activate MIX as soon as it comes online, but a client may also choose to only activate MIX for specific periods.
+
+
+
+
+ coven@mix.shakespeare.lit
+ spells@mix.shakespeare.lit
+
+
+
+
+
+
+]]>
+
+
+ A client will deactivate MIX using a corresponding deactivate command. This will deactivate all MIX channels. This will often be done when the client closes down, but may also be done at other times the client chooses. Deactivation uses an IQ set with an <deactivate> element to instruct the MIX proxy to activate the client.
+
+
+
+
+
+
+
+
+
+]]>
+
+
+ If a client goes offline, the server's MIX Proxy MUST deactivate MIX immediately. This will mean that standard client behaviour will be to activate MIX when they come online.
+
+
+
+
+
+
+ Messages from a MIX channel will usually go to the MIX proxy. 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 MIX Proxy. The MIX Proxy will simply send on the messages from the channel to each of the user's clients which have activated the channel with the MIX Proxy. If there are no clients activated, the message is dropped.
+
+
+ Messages sent to the MIX Proxy will always be addressed to the user's bare JID. The MIX proxy will modify the recipient to the full JID of each client to which the message is forwarded. The MIX Proxy MUST NOT make any other modifications to each message.
+
+
+
+
+
+ The MIX specification requires that some messages are sent through the MIX Proxy and allows other messages to be sent through the MIX Proxy. This enables the MIX Proxy to use information from the client to improve the MIX Proxy function. The messages sent by the client to the MIX proxy will come from the client's full JID. The MIX proxy will modify the messages to come from the bare JID. This modification is transparent to the MIX client. The client will always send messages from the full JID and the MIX Proxy will modify the message to ensure MIX compliance.
+
+
+
+
+ The MIX Proxy is responsible for ensuring that MIX channels are correctly entered into the user's roster. This is provided as a generic client independent service for the user.
+
+
+ The MIX Proxy SHOULD ensure that only presence information from activated MIX clients is sent to the MIX channel. So, if a user has two online clients, but only one is activated for a given MIX channel, then the channel SHOULD only receive presence information relating to the activated client.
+
+
+
+
+
+ MAM Archive is not a part of the MIX Proxy. However, it is important to note that archive of channel information is done by the user's server. Where a message is sent to the MIX Proxy and discarded because there are no active clients, it will still be archived. This means that the messages will be available in the local archive and can be picked up by clients when they come online.
+
+
+
+
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.
@@ -1998,57 +2115,55 @@ A client creates a channel by sending a simple request to the MIX service. A c
+
+ This section lists a number of capabilities not specified in this version of MIX which were provided in &xep0045;.
+
+
+ &xep0045; provides a mechanism to control access to MUC rooms using passwords. An equivalent mechanism is not included in MIX, as it has a number of security issues. Control of access to channels is better achieved using an explicit list of participants.
+
+
+
+
+ &xep0045; defines a mechanism so that MUC moderators can control who is able to send messages to a MUC room using a "voice" mechanism. The current version of MIX does not include this. This might be added to a future version of this XEP or as a separate XEP if this capability becomes an agreed requirement.
+
+
-
-
-
- This section lists a number of capabilities not specified in this version of MIX which were provided in &xep0045;.
-
-
- &xep0045; provides a mechanism to control access to MUC rooms using passwords. An equivalent mechanism is not included in MIX, as it has a number of security issues. Control of access to channels is better achieved using an explicit list of participants.
-
-
-
-
- &xep0045; defines a mechanism so that MUC moderators can control who is able to send messages to a MUC room using a "voice" mechanism. The current version of MIX does not include this. This might be added to a future version of this XEP or as a separate XEP if this capability becomes an agreed requirement.
-
-
-
-
- TBD.
- Discuss normalization of nicknames.
+ MIX allows specification of a number of human readable strings associated with a MIX channel, in particular the subject of a MIX channel and name and description information. These strings may have language set using an xml:lang attribute, and multiple values may be set provided that each one is distinguished using xml:lang.
+
+
+ Nicknames SHOULD be normalized using the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;.
+
- TBD.
- Topics to cover:
-
- - transparent vs. opaque channels
- - nickname registration and security implications of normalization
-
+ MIX is built over MAM and PubSub and the security considerations of &xep0313; and &xep0060; should be considered. These services protect MIX channel information, which may be sensitive and needs appropriate protection.
+ MIX channels may be JID Hidden, in order to hide the JIDs of channel participants from those accessing the channel. Care must be taken to ensure that JIDs are fully hidden. In particular when proxy JIDs are prepared, this MUST be done in a manner which ensure that the real JIDs cannot be determined. Where nicks are assigned by a channel, this MUST be done in a way that does not expose the JID.
+
+ There is no MIX equivalent to &xep0045; password controlled rooms, which avoids a number of security issues.
+
+
+ MIX provides flexible access control options, which should be used in a manner appropriate to the security requirements of MIX users and services.
+
+
+
None.
+
- Register a namespace.
+ The urn:xmpp:mix namespace must be registered.
+
- TBD.
+ To be supplied when MIX progresses to proposed standard.
+
- Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Matthew Wild and one anonymous reviewer.
+ Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Matthew Wild and one anonymous reviewer.
+
-
diff --git a/xep.ent b/xep.ent
index 3dafd7cd..01d49dd1 100644
--- a/xep.ent
+++ b/xep.ent
@@ -886,6 +886,14 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates
kevin.smith@isode.com
" >
+
+ Steve
+ Kille
+ steve.kille@isode.com
+ steve.kille@isode.com
+
+" >
Remko