moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Edits

This commit is contained in:
Steve Kille 2018-05-21 14:13:26 +01:00
parent 717a974d08
commit 3f6f3e77f8
1 changed files with 567 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

567
xep-0404.xml Normal file
View File

@ -0,0 +1,567 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<?xml-stylesheet type="text/css" href="xmpp.css"?>
<xep>
<header>
<title>Mediated Information eXchange (MIX): JID Hidden Channels.</title>
<abstract>This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369. This specification extends MIX to provide a number of privacy control options and in particular JID Hidden Channels. </abstract>
&LEGALNOTICE;
<number>0404</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0054</spec>
<spec>XEP-0060</spec>
<spec>XEP-0084</spec>
<spec>XEP-0128</spec>
<spec>XEP-0198</spec>
<spec>XEP-0292</spec>
<spec>XEP-0297</spec>
<spec>XEP-0313</spec>
<spec>XEP-0369</spec>
<spec>XEP-0372</spec>
<spec>XEP-0403</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>MIX-ANON</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.1.0</version>
<date>2018-05-21</date>
<initials>sek</initials>
<remark><p>
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capbilities are specified in &xep0369; (MIX-CORE).
</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p></p>
</section1>
<section1 topic='Concepts' anchor='concepts'>
<section2 topic="Private Messages" anchor="concepts-pm">
<p>
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.
</p>
</section2>
<section2 topic="Proxy JIDs and JID Visibility" anchor="proxy-jid">
<section3 topic="Services Provided" anchor="proxy-jid-services">
<p>
MIX channels have three modes controlling JID visibility:
</p>
<table caption="JID Visibility Modes">
<tr><th>Mode</th><th>Description</th></tr>
<tr><td>'JID Visible'</td><td>In these channels all participant JIDs are visible to all channel participants.</td></tr>
<tr><td>'JID Maybe Visible'</td><td>In these channels, participant JIDs are visible to all channel participants when participant preference allows.</td></tr>
<tr><td>'JID&nbsp;Hidden'</td><td>In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators.</td></tr>
</table>
<p>
A channel participant MAY specify a preference for JID visibility for the channel, with one of the following values:
</p>
<table caption="JID Visibility Preference Options">
<tr><th>Preference</th><th>Description</th></tr>
<tr><td>'Prefer Visible'</td><td>The users JID will be visible if the channel is JID Visible or JID Maybe Visible channels and hidden if the channel is JID Hidden. </td></tr>
<tr><td>'Prefer Hidden'</td><td>The user's JID will be hidden if the channel is JID Maybe Visible and shown if the channel is JID Visible .</td></tr>
<tr><td>'Enforce Hidden'</td><td>The user's JID will never be shown and the user will be removed from channel if channel mode is changed to JID Visible.</td></tr>
<tr><td>'Enforce Visible'</td><td>The users JID will always be shown and the user will be removed from channel if mode is changed to 'JID Hidden'.</td></tr>
</table>
<p>
The default value is 'Prefer Hidden'.
</p>
</section3>
<section3 topic="Architecture" anchor="proxy-jid-architecture">
<p>
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:
</p>
<ol>
<li>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.</li>
<li>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.</li>
<li>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. </li>
</ol>
</section3>
<section3 topic="Detailed Specification" anchor="proxy-jid-specification">
<p>
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 "&lt;generated identifier&gt;#&lt;channel&gt;@&lt;mix domain&gt;". 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</section3>
</section2>
<section2 topic="JID Map Node" anchor="concepts-nodes">
<p>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:</p>
<table caption="Standard MIX Nodes">
<tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td><td>Automatic</td><td>PubSub</td></tr>
</table>
<section3 topic="JID Map Node" anchor="jid-map-node">
<p>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 &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:1' namespace. The real JID is stored in a &lt;jid/&gt; child element of the &lt;participant/&gt; element. </p>
<example caption="Value of JID Map Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='123456#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:1'>
<jid>hecate@mix.shakespeare.example</jid>
</participant>
</item>
</items>
]]></example>
</section3>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Common User Use Cases' anchor='usecases-user'>
<section3 topic="User Preferences and Additional Information" anchor="usecase-visibilty-pref">
<p>A channel MAY store user preferences and parameters with each user. A user JID visibility preference has the following values:
</p>
<ol>
<li>'default'. In this setting, the channel default value will be used. This value is used if another value is not explicitly set. This means JID is visible for a JID Visible channel and JID is hidden for JID Hidden and JID Maybe Visible channels.</li>
<li>'never'. If this is set, JID will never be shared and user will be removed from the channel if its mode changes to JID Visible.</li>
<li>'always'. If this is set, JID will always be shared and users will be removed from the channel if its mode changes to JID Hidden.</li>
<li>'prefer not'. If this is set, JID will only be shared if mode is JID Visible.</li>
</ol>
<p>
The user MAY specify that no Private Messages are to be sent from the channel, and allow vCard retrieval.
</p>
<p>
The user MAY specify that presence is not to be shared, which will prevent the MIX Channel from sending a presence probe for the user on channel start-up. The user will also choose to not include the MIX channel in the user's roster, so that presence will not be updated. Where the channel configuration sets 'Participants Must Provide Presence', this variable MUST be set to 'Share'.
</p>
<p>
The following table sets out the standardized user preference values. A MIX implementation MAY use other values.
</p>
<table caption="Standard User Preference Options">
<tr><th>Option</th> <th>Values</th><th>Default</th></tr>
<tr><td>'JID Visibility'</td> <td>'default', 'never', 'always', 'prefer not'</td> <td>'default'</td></tr>
<tr><td>'Private Messages'</td><td>'allow', 'block'</td> <td>'allow'</td></tr>
<tr><td>'vCard'</td><td>'allow', 'block'</td> <td>'block'</td></tr>
<tr><td>'Presence'</td><td>'share', 'not share'</td><td>'share'</td></tr>
</table>
<p>When joining a channel, the client MAY specify one or more preference options as a &xep0004; form. In the response, the server MUST specify all of the user preferences supported by the server, with default values if the user has not requested a different value. The following example shows joining a channel and setting a preference. The following example shows the message sent from the user's server to the MIX channel, which will have been preceded by a message from the user's client to the user's server.</p>
<example caption="User Joins a Channel and Specifies a preference"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:1</value>
</field>
<field var='JID Visibility'>
<value>never</value>
</field>
</x>
</join>
</iq>
]]></example>
<p>The following example shows the result of a successful join, which also reports all the user preferences. This example shows the message coming from the MIX channel to the user's server, which will be sent on to the user.</p>
<example caption="Channel Successfully Processes Join and returns the preferences set"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:1' jid='hag66@shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:1</value>
</field>
<field var='JID Visibility'>
<value>never</value>
</field>
<field var='Private Messages'>
<value>allow</value>
</field>
<field var='vCard'>
<value>block</value>
</field>
</x>
</join>
</iq>
]]></example>
<p>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 &lt;user-preference/&gt; child element of &lt;iq/&gt;. &lt;user-preference/&gt; is qualified by the 'urn:xmpp:mix:1' namespace. The result is encoded as a form child element in the &lt;user-preference/&gt; element.</p>
<example caption="User Requests and Recieves Preferences Template Form"><![CDATA[
<iq type='get'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:1'/>
</iq>
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:1'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:1</value>
</field>
<field type='list-single' label='Preference for JID Visibility
var='JID Visibility'>
<option label='JID Never Shown'><value>Never</value></option>
<option label='Default Behaviour'
<value>default</value></option>
<option label='Try not to show JID'>
<value>prefer not</value></option>
</field>
<field type='list-single' label='Example Custom Preference'
var='Custom Preference'>
<option label='One Option'><value>a</value></option>
<option label='Another Option'><value>b</value></option>
</field>
</x>
</user-preference>
</iq>
]]></example>
<p>
A user MAY modify preferences using the corresponding set operation. The set MAY specify values for some or all attributes. All attributes are returned in the result.
</p>
<example caption="User Updates Preferences"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:1'/>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:1</value>
</field>
<field var='JID Visibility'>
<value>never</value>
</field>
<field var='Private Messages'>
<value>allow</value>
</field>
<field var='vCard'>
<value>block</value>
</field>
</x>
</iq>
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:1'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:1</value>
</field>
<field var='JID Visibility'>
<value>never</value>
</field>
<field var='Private Messages'>
<value>allow</value>
</field>
<field var='vCard'>
<value>block</value>
</field>
</x>
</user-preference>
</iq>
]]></example>
</section3>
<section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
<p>
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.
</p>
<p>
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:
</p>
<example caption='Client looks up Real JID from Proxy JID'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
to='coven@mix.shakespeare.example'
type='get'>
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='123456#coven@mix.shakespeare.example'/>
</items>
</pubsub>
</iq>
<iq from='coven@mix.shakespeare.example'
id='kl2fax27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='123456#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:1'>
<jid>hecate@mix.shakespeare.example</jid>
</participant>
</item>
</items>
</pubsub>
<items>
</iq>]]> </example>
<p>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. </p>
<p>
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:
</p>
<example caption='Client looks up Real JID from Proxy JID in MAM Archive'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
to='coven@mix.shakespeare.example'
type='set'>
<query xlns='urn:xmpp:mam:2'
queryid='f28'
node='urn:xmpp:mix:nodes:jidmap'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mam:2</value>
</field>
<field var='id'>
<value>123456#coven@mix.shakespeare.example</value>
</field>
</x>
</query>
</iq>
<message id='iasd208' to='hag66@shakespeare.example/UUID-c8y/1573'>
<result xmlns='urn:xmpp:mam:2' queryid='f28' id='28482-20987-73623'>
<forwarded xmlns='urn:xmpp:forward:0'>
<delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
<message xmlns="jabber:client">
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='123456#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:1'>
<jid>hecate@mix.shakespeare.example</jid>
</participant>
</item>
</items>
</event>
</message>
</forwarded>
</result>
</message>
<iq from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
type='result'>
</iq>]]> </example>
</section3>
<section3 topic='Going Offline' anchor='usecase-user-offline'>
<p>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.</p>
<example caption="Client Goes Offline in the Channel"><![CDATA[
<presence type='unavailable'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'/>
]]></example>
<p>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:</p>
<example caption="Channel Distributes Notification of Client going Offline">
<![CDATA[<presence from='12345#coven@mix.shakespeare.example/678'
to='hecate@shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='unavailable'/>]]></example>
<p>
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.
</p>
<p>
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.
</p>
</section3>
<section3 topic='Sending Private Messages' anchor='usecase-user-private-messages'>
<p>
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.
</p>
<table caption="Setting From and To when sending Private Messages">
<tr><th>Message</th><th>From</th><th>To</th></tr>
<tr><td>First Message from Client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy bare JID of responder</td></tr>
<tr><td>First Message from MIX Channel to responder's server</td><td>Proxy full JID of initiator's client</td><td>Bare JID of responder</td></tr>
<tr><td>First Message from responder's server to one or more of the responder's clients</td><td>Proxy full JID of initiator</td><td>Full JID of responder's client</td></tr>
<tr><td>Messages from responder's client to MIX Channel</td><td>Full JID of responder's client</td><td>Proxy full JID of initiator's client</td></tr>
<tr><td>Messages from MIX channel to initiator's client</td><td>Proxy full JID of responder's client</td><td>Full JID of initiator's client</td></tr>
<tr><td>Messages from initiator's client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy full JID of responder's client</td></tr>
<tr><td>Message from MIX Channel to responder's client</td><td>Proxy full JID of initiator's client</td><td>Full JID of responder's client</td></tr>
</table>
<p>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.</p>
</section3>
<section3 topic="Requesting vCard" anchor="usecase-vcard">
<p>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.</p>
<example caption="Client directly requests vCard through channel" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='lx09df27'
to='989898#coven@mix.shakespeare.example'
type='get'>
<vCard xmlns='vcard-temp'/>
</iq>
]]></example>
<p>The MIX channel MAY pass on the vCard request or MAY reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the user's server (using bare JID) using a full proxy JID to hide the requester. </p>
<example caption="Channel passes on vCard request to the User&apos;s Server" ><![CDATA[
<iq from='123456#coven@mix.shakespeare.example/6789'
id='lx09df27'
to='peter@shakespeare.example'
type='get'>
<vCard xmlns='vcard-temp'/>
</iq>
]]></example>
<p>
The user's server, on behalf of the user, MAY send a response or reject with an error. The user's server will send the vCard back to the channel.
</p>
<example caption="User's Server sends vCard Response via MIX channel" ><![CDATA[
<iq from='peter@shakespeare.example'
id='lx09df27'
to='123456#coven@mix.shakespeare.example/6789'
type='result'>
<vCard xmlns='vcard-temp'>
<FN>Peter Saint-Andre</FN>
<N>
<FAMILY>Saint-Andre</FAMILY>
<GIVEN>Peter</GIVEN>
<MIDDLE/>
</N>
<NICKNAME>stpeter</NICKNAME>
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
</vCard>
<query xmlns='http://jabber.org/protocol/disco#info'>
</iq>
]]></example>
<p>
The MIX channel will then send the vCard response to the requesting client on behalf of the client sending the response.
</p>
<example caption="MIX Channel sends vCard responst to Client" ><![CDATA[
<iq from='989898#coven@mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
<vCard xmlns='vcard-temp'>
<FN>Peter Saint-Andre</FN>
<N>
<FAMILY>Saint-Andre</FAMILY>
<GIVEN>Peter</GIVEN>
<MIDDLE/>
</N>
<NICKNAME>stpeter</NICKNAME>
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
</vCard>
</iq>
]]></example>
</section3>
</section2>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>See considerations in MIX-CORE.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>See considerations in MIX-CORE.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>None.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The urn:xmpp:mix namespace needs to be registered.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>To be supplied when MIX progresses to proposed standard.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>See MIX-CORE for a list of contributors to the MIX Family of specifications.</p>
</section1>
</xep>