diff --git a/xep-0404.xml b/xep-0404.xml index 69b708e8..dcaccebf 100644 --- a/xep-0404.xml +++ b/xep-0404.xml @@ -48,17 +48,12 @@ -

The Mediated Information eXchange (MIX) protocol framework and core capbilities are specified in &xep0369; (MIX-CORE). - +

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.

- -

- - @@ -69,17 +64,18 @@

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

- - + +

- MIX channels have three modes controlling JID visibility: + MIX channels have three modes controlling JID visibility, defined to prevent JID harvesting:

@@ -100,45 +96,50 @@

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

    -
  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. +
  4. The requirement to include real JID in the participants list is relaxed for channels that are not "JID Visible". For a "JID Hidden" channel, real JIDs MUST NOT be included in the participants list. For a "JID Maybe Visible" channel, real JIDs will be included in the participants node according to participant preference.
    5. +
  5. In presence messages, the client resource is anonymized, to prevent leakage of information through the resource.
- + + +

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

+ +

+ It is important that MUC owners and administrators are able to see the real JIDs of participant. For this reason, a MIX channel following this specification MUST hold a JID Map node, which gives a mapping between proxy JID and real JID. +

+ + + - + -

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

-

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

-

- The example real full JIDs in this specification are aligned the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client and is anticipated to be a fixed format which may well be UUID 4. The second part is server assigned and will vary with each session. A realistic JID with resource is: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f2cd'. This specification uses examples of the style: 'hag66@shakespeare.example/UUID-a1j/7533' which are aligned to real resources, but more compact. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated. -

+ +

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

- + - + -

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:

-
ModeDescription
+

This specification defines a JID Map node, so that administrators can see real JIDs for JID Hidden channels.

+
@@ -147,33 +148,32 @@ -

The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel. Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub. - In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.

+ In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:anon:0' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.

- + hecate@mix.shakespeare.example ]]> - + - + - + - +

A channel MAY store user preferences and parameters with each user. A user JID visibility preference has the following values:

@@ -205,12 +205,12 @@ from='hag66@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:1 + urn:xmpp:mix:anon:0 never @@ -225,12 +225,12 @@ from='coven@mix.shakespeare.example' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:1 + urn:xmpp:mix:anon:0 never @@ -245,23 +245,23 @@ ]]> -

The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> child element of <iq/>. <user-preference/> is qualified by the 'urn:xmpp:mix:1' namespace. The result is encoded as a form child element in the <user-preference/> element.

+

The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> child element of <iq/>. <user-preference/> is qualified by the 'urn:xmpp:mix:anon:0' namespace. The result is encoded as a form child element in the <user-preference/> element.

- + - + - urn:xmpp:mix:1 + urn:xmpp:mix:anon:0 @@ -288,10 +288,10 @@ from='hag66@shakespeare.example/UUID-a1j/7533' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:1 + urn:xmpp:mix:anon:0 never @@ -309,10 +309,10 @@ from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:1 + urn:xmpp:mix:anon:0 never @@ -327,134 +327,17 @@ ]]> - + - -

- Presence information will provide a MIX client with the nicks and proxy JIDs for participants in a channel. Messages sent to a channel and retrieved from MAM archives will show the proxy JID and nick of the sender. It is sometimes useful to determine the real JID associated with proxy JID. This can always be done for JID Visible channels and can sometimes be done for JID Maybe Visible channels. - -

-

- For current users JID visible rooms, the real JID is found by a PubSub lookup on the JID Map node. This is shown in the following example: -

- - - - - - - - - - - - - - - hecate@mix.shakespeare.example - - - - - -]]> - - -

For JID Maybe Visible rooms the lookup is performed on the JID Maybe Visible Map node. Note that where a user prefers to not share real JID, the result of this lookup of proxy JID will be the (same) proxy JID.

- -

- When an older message is considered, it is possible that the proxy JID of the sender is not current. Such a JID can be looked up in the MAM Archive of the JID Map Node. This is shown in the following example: -

- - - - - urn:xmpp:mam:2 - - - 123456#coven@mix.shakespeare.example - - - - - - - - - - - - - - - hecate@mix.shakespeare.example - - - - - - - - - - -]]> - - - - - - - - -

When a client goes offline, this presence update is sent by the client's server to the MIX channel. From the client perspective, this is the same as any other presence change. Handling by the MIX channel is slightly different.

- -]]> -

The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID. The MIX channel will notify subscribers to the presence node of the user going offline by sending a presence stanza to the full JID of each client. The presence stanza will reference the full proxy JID of the client that is going offline, as shown in the following example:

- - -]]> - -

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

-

- It is desirable to prevent clients from going offline briefly and then coming back online again, as this will lead to "flapping presence". The RECOMMENDED approach to achieve this is use of &xep0198; to maintain an XMPP client connection in the event of short term TCP failure. -

- - - - +

- Private Messages are used to provide communication with another channel participant through the MIX channel, without the initiating user knowing the real JID of the channel participant. A channel MAY support use of Private Messages. Private messages are standard XMPP messages and MUST NOT be groupchat. A message goes through a number of stages with different addressing. This is set out in the following table. + Private Messages are used to provide communication with another channel participant through the MIX channel, where the initiating user does not the real JID of the channel participant. A channel MAY support use of Private Messages. Private messages are standard XMPP messages and MUST NOT be groupchat. A message goes through a number of stages with different addressing. This is set out in the following table.

JID Map'urn:xmpp:mix:nodes:jidmap'For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.AutomaticPubSub
@@ -467,12 +350,12 @@
MessageFromTo
Message from MIX Channel to responder's clientProxy full JID of initiator's clientFull JID of responder's client

Private Messages MAY be archived using MAM by the XMPP servers associated with initiator and responder. Private Messages MUST NOT be archived by the MIX channel.

- + - -

A client MAY request the vCard of a channel participant by sending a request through the channel. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). The MIX channel does not process the vCard requests, but simply relays them on to real bare JID of the target. A MIX service MAY choose to relay one or both protocols. Where a MIX service relays one or both of these protocols, each protocol relayed MUST be advertised as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the bare proxy JID of the channel participant for which the vCard is desired.

+ +

A client MAY request the vCard of a channel participant where the participant's real JID is not known, by sending a request through the channel. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). The MIX channel does not process the vCard requests, but simply relays them on to real bare JID of the target. A MIX service MAY choose to relay one or both protocols. Where a MIX service relays one or both of these protocols, each protocol relayed MUST be advertised as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the bare proxy JID of the channel participant for which the vCard is desired.

]]> - - - + + +

See considerations in MIX-CORE.