diff --git a/xep-0369.xml b/xep-0369.xml index ac025c8b..ad02ab27 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -36,6 +36,14 @@ &ksmithisode; &skille; + 0.11.4 + 2018-06-05 + sek +

+ Remove Proxy JID; + Add Stable Participant ID; +

+ 0.11.3 2018-05-24 sek @@ -432,7 +440,7 @@
  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. &xep0403;. 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-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. It also specifies relay of IQ stanzas through a channel.
  4. MIX-PAM. &xep0405;. This specification defines how a server supporting MIX clients behaves, to support servers implementing MIX-CORE and MIX-PRESENCE.
  5. MIX-ADMIN. &xep0406;. This specifies MIX configuration and administration of MIX.
  6. MIX-ANON. &xep0404;. This specifies a mechanism to hide real JIDs from MIX clients and related privacy controls.
    7. @@ -486,9 +494,7 @@
  7. In MIX, a Nick belongs to the user and not to each client.
    8. -
  8. - Presence is exchanged in MIX by use of a proxy JID, which is a stable JID on the domain of the MIX channel that identifies the user. This proxy JID is used instead of the "Nick as a Resource" mechanism in MUC. To support this, the proxy JID is a primary part of defining a MIX channel participant. Proxy JIDs are also used in MIX-ANON to provide a "JID Hidden" mechanism, to give a service similar to MUC semi-anonymous, that will prevent JID harvesting (requirement 7). -
    9. +
@@ -514,7 +520,9 @@
  • Presence is sent to participants using bare JID, whether or not the user has an online client.
  • Online clients MAY register presence, which is then shared with participants who have subscribed to presence.
  • MIX decouples addressing of channel participants from their nicknames, so that nickname changes do not affect addressing.
    • -
  • Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource (also anonymized) are then constructed, allowing visibility into the number of online resources participating in a channel.
    • +
  • Each participant has a Stable Participant ID. This is used in some derived JIDs to provide a stable participant reference. It is used to hide JIDs in MIX-ANON. + +
  • Although some protocol is shared with MUC, MUC clients are not interoperable with a MIX service.
  • MIX requires the server to which the MIX client connects to provide functionality to support MIX. This functionality is defined in this specification and referenced as "MIX Participant's Server Behaviour".
  • MIX domains MUST NOT be used to host end user JIDs.
    • @@ -531,17 +539,15 @@ - +

    - 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 includes and encoding of the name of the channel and a random identifier. The primary reason for proxy JID is to support presence, as presence messages need to be sent from the domain of the MIX channel. MUC achieves this by using the resource to encode Nick, which does not work well. Proxy JIDs enable Nick changing and support of multiple clients (as the client resource can be shared). MIX provides a simple mechanism for clients to map the proxy JID to Nick and Real Jid, so that these are available to the MIX user. Proxy JIDs are also used to provide the "JID Hidden" mechanism, specified in MIX-ANON. + Every channel participant is identified by a Stable Participant ID, which uniquely identifies a channel participant and never changes. The Stable Participant ID MUST NOT contain the '#', '/' or '@' characters.

    +

    - Proxy JIDs are 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'. 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. -

    -

    - The mapping of real bare JID to proxy JID is defined when a participant joins a channel. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed. This mapping must be maintained after the user leaves the channel. Proxy JID values MUST NOT be re-used. If a JID that left a channel joins the channel again, the same proxy JID MAY be used again or a different new proxy JID MAY be assigned. + A Participant's Stable Participant ID is defined when a participant joins a channel. While a user is a participant in a Channel, the Stable Participant ID MUST NOT be changed. This mapping between Participant and Stable Participant ID MUST be maintained after the participant leaves the channel. Stable Participant ID values MUST NOT be re-used. If a participant that left a channel joins the channel again, the same Stable Participant ID MAY be used again or a different Stable Participant ID MAY be assigned.

    @@ -580,7 +586,7 @@ -

    Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:core:0' namespace. The nick associated with the user is optional and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants. +

    Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the Stable Participant ID of the participant. For example '123456' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:core:0' namespace. The nick associated with the user is optional and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.

    A Nick MAY be associated with a participant. The nick associated with the user is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants. @@ -590,18 +596,18 @@ The user's JID is stored in a <jid/> child element of the <participant/> element.

    - When a user joins a channel, the user's bare proxy JID is added to the participants node by the MIX service. When a user leaves a channel, the user's bare proxy JID is removed from the participants node. The participants node MUST NOT be directly modified using pubsub. + When a user joins a channel, an item representing the is added to the participants node by the MIX service. When a user leaves a channel, the user's item is removed from the participants node. The participants node MUST NOT be directly modified using pubsub.

    - Clients will need to read the Participants node to provide useful display of presence information. For this reason, it is anticipated that Participants will be able to read the Participants node. However, for the message distribution specified in MIX-CORE, it is not necessary for clients to be able to read the Participants node. + It may be useful for clients to read the participants list. However it is not necessary for message and presence display, as both messages and presence contain sufficient information to enable display.

    Users MAY subscribe to and read information this node, when permitted by the channel. Standard PubSub access will allow a full list of participants and associated nicks to be determined. By subscribing to the node, a user will be informed of changes to the Participants Node.

    -

    The participants node is OPTIONAL. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used. The Participants node is a permanent node with one item per participant.

    +

    The participants node is MANDATORY. The Participants node is a permanent node with one item per participant.

    - + thirdwitch hag66@shakespeare.example @@ -668,7 +674,7 @@
    1. IQ. All of the IQ errors of &rfc6120; MUST be supported.
    2. Messages. If a message is received and an error situation is encountered, a message of type error MUST be sent back to the message sender. This message format is specified in &rfc6121; containing an error defined in &rfc6120;, which is the same error set as for IQs.
      3. -
    3. Presence. Any responses to presence messages MUST follow the rules of &rfc6121;.
      4. +
    4. Presence. If MIX-PRESENCE is supported, any responses to presence messages MUST follow the rules of &rfc6121;.
    5. PubSub. Where MIX protocol messages use PubSub protocol, the errors defined in &xep0060; MUST be used and supported.
    @@ -853,7 +859,8 @@

    - Participants in the channel are determined using PubSub retrieval of the Participants Node which will give proxy JID, real JID and nick. It is anticipated that clients using a channel will often determine participants on start-up, to enable display of participants and presence.

    + Participants in the channel are determined using PubSub retrieval of the Participants Node which will give Stable Participant + ID, JID and nick. Clients using a channel MAY determine participants on start-up, to enable display of participants.

    - + thirdwitch hag66@shakespeare.example - + top witch hecate@shakespeare.example @@ -944,14 +951,15 @@ ]]> -

    The channel responds to the user's sever with an IQ-result addressed to the user's bare JID, which will be processed as specified in MIX-PAM. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. The JID returned in the join is the user's bare proxy JID. The following example shows the result of the above request when the request is completed in full.

    +

    The channel responds to the user's sever with an IQ-result addressed to the user's bare JID, which will be processed as specified in MIX-PAM. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. The user's Stable Participant ID is returned as an 'id' attribute in the join. + The following example shows the result of the above request when the request is completed in full.

    + id='123456'> @@ -988,7 +996,7 @@ id='5A9C7398-DB13-4BFA-A091-2D466C710AAF'> - + hag66@shakespeare.example @@ -997,7 +1005,7 @@ ]]> -

    The user that has been added to the channel is identified by the item id of the item added to the Participants node, which is the proxy JID of the new channel participant. The <participant> element MUST include a <jid> element with the JID of the participant, unless MIX-ANON is being followed to hide participant JIDs. The <nick> element will not be included at this point, unless it is automatically generated by the channel. In the likely event that a Nick is subsequently added, an update with the <nick> element will be distributed. +

    The user that has been added to the channel is identified by the item id of the item added to the Participants node, which is the Stable Participant ID of the new channel participant. The <participant> element MUST include a <jid> element with the JID of the participant, unless MIX-ANON is being followed to hide participant JIDs. The <nick> element will not be included at this point, unless it is automatically generated by the channel. In the likely event that a Nick is subsequently added, an update with the <nick> element will be distributed.

    @@ -1132,9 +1140,11 @@

    1. A <nick> element that contains the Nick of the message sender, taken from the Participants Node. This MUST be present if a Nick is defined for the user.
      2. -
    2. A <jid> element containing the real JID of the sender. This MUST be present, unless following the "JID Hidden" model defined in MIX-ANON. If this element is omitted, the <nick> and <proxy-jid> elements MUST be present.
      3. -
    3. A <proxy-jid> element contains the sender's proxy JID. This MUST be present if <jid> is omitted and MUST not be present if <jid> is present.
      4. +
    4. A <jid> element containing the real JID of the sender. This MUST be present, unless following the "JID Hidden" model defined in MIX-ANON. If this element is omitted, the <nick> element MUST be present.
    +

    + MIX messages are distributed by the channel with the from using the JID of the channel, with the Stable Participant ID of the sender in the resource. This enables a receiving system to distinguish messages based on sender using on the JID. +

    The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server as specified in MIX-PAM. The message 'from' attribute is the JID of the channel. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' attribute.

    @@ -1152,7 +1162,7 @@ ]]> @@ -1164,18 +1174,7 @@ ]]> - - Harpier cries: 'tis time, 'tis time. - - thirdwitch - 123456#coven@mix.shakespeare.example - - -]]> +

    The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional <submission-id> element in the <mix> element of the message copy going back to the originator's bare JID. The <submission-id> element holds the original id provided by the sender. This enables the originator to correlate the received message with the message submitted.

    @@ -1362,7 +1361,7 @@

    MIX is built over MAM and PubSub and the security considerations of &xep0313; and &xep0060; MUST be considered. These services protect MIX channel information, which can 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.