+ Editorial Changes (addressing comments from Timothée Jaussoin); +
Editorial Changes (mainly from Georg Lukas);
@@ -813,7 +821,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='kl2fax27'
to='coven@mix.shakespeare.lit'
type='get'>
-
- 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. + 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.
@@ -1068,10 +1076,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The user MAY specify that no Private Messages are to be sent from the channel, and allow vCard retrieval. @@ -1084,10 +1092,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
| Option | Values | Default |
|---|---|---|
| 'JID Visibility' | 'Default', 'Never', 'Always', 'Prefer Not' | 'Default' |
| 'Private Messages' | 'Allow', 'Block' | 'Allow' |
| 'vCard' | 'Allow', 'Block' | 'Block' |
| 'Presence' | 'Share', 'Not Share' | 'Share' |
| 'JID Visibility' | 'default', 'never', 'always', 'prefer not' | 'default' |
| 'Private Messages' | 'allow', 'block' | 'allow' |
| 'vCard' | 'allow', 'block' | 'block' |
| 'Presence' | 'share', 'not share' | 'share' |
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.
Invitation by reference, as described in the previous section, is a convenient approach to invite a user to join a channel that the user has permission to join. This section describes the approach used when the inviter has permission to grant rights for the invitee to become a channel participant. This might be because the inviter is an administrator of the channel or the channel has a special mode where channel participants are allowed to grant rights for other users to join a channel enabled ('Participation Addition by Invitation from Participant'). This approach is used to avoid cluttering the allowed node with JIDs of users who are invited to join, but do not accept the invitation. +
Invitation by reference, as described in the previous section, is a convenient approach to invite a user to join a channel that the user has permission to join. This section describes the approach used when the inviter has permission to grant rights for the invitee to become a channel participant. This might be because the inviter is an administrator of the channel or the channel or if the inviter is a channel participant and the channel allows invitation by participants (this channel capability is controlled by the channel configuration variable 'Participation Addition by Invitation from Participant'). Invitation by reference is used to avoid cluttering the allowed node with JIDs of users who are invited to join, but do not accept the invitation. When a channel participant(the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:
@@ -1704,7 +1712,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa- The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel has 'Participation Addition by Invitation from Participant' mode enabled. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. + The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time.
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 MAY be sent by the user's server on behalf of the user. 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 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 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.