mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
Editorial Changes (addressing comments from Timothée Jaussoin)
This commit is contained in:
Steve Kille
Sam Whited
parent
5a99a3d565
commit
a09053ebd2
74
xep-0369.xml
74
xep-0369.xml
@ -36,9 +36,17 @@
|
||||
&ksmithisode;
|
||||
&skille;
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>0.9.1</version>
|
||||
<date>2017-03-29</date>
|
||||
<initials>sek</initials>
|
||||
<remark><p>
|
||||
Editorial Changes (addressing comments from Timothée Jaussoin);
|
||||
</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.9</version>
|
||||
<date>2017-03-27</date>
|
||||
<date>2017-03-22</date>
|
||||
<initials>sek</initials>
|
||||
<remark><p>
|
||||
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'>
|
||||
<pubsub xlns='http://jabber.org.protocol.pubsub'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:nodes:info'/>
|
||||
</pubsub>
|
||||
</iq>
|
||||
@ -823,7 +831,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
id='kl2fax27'
|
||||
to='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
type='result'>
|
||||
<pubsub xlns='http://jabber.org.protocol.pubsub'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:nodes:info>>
|
||||
<item>
|
||||
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'>
|
||||
@ -856,7 +864,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
id='kl2fax27'
|
||||
to='coven@mix.shakespeare.lit'
|
||||
type='get'>
|
||||
<pubsub xlns='http://jabber.org.protocol.pubsub'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:nodes:participants'/>
|
||||
</pubsub>
|
||||
</iq>
|
||||
@ -866,7 +874,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
id='kl2fax27'
|
||||
to='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
type='result'>
|
||||
<pubsub xlns='http://jabber.org.protocol.pubsub'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:nodes:participants'>
|
||||
<item jid='123456#coven@mix.shakespeare.example' nick='thirdwitch'>
|
||||
<item jid='87123#coven@mix.shakespeare.example' nick='top witch'>
|
||||
@ -1051,7 +1059,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
This roster entry will lead to the user's server correctly sending user's presence from all the user's MIX clients to the MIX channel. Where the user wishes to share presence, the roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel to the user.
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
|
||||
</p>
|
||||
<p>
|
||||
@ -1068,10 +1076,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</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>
|
||||
<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.
|
||||
@ -1084,10 +1092,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</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>
|
||||
<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[
|
||||
@ -1103,7 +1111,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<field var='JID Visibility'>
|
||||
<value>Never</value>
|
||||
<value>never</value>
|
||||
</field>
|
||||
</x>
|
||||
</join>
|
||||
@ -1123,13 +1131,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<field var='JID Visibility'>
|
||||
<value>Never</value>
|
||||
<value>never</value>
|
||||
</field>
|
||||
<field var='Private Messages'>
|
||||
<value>Allow</value>
|
||||
<value>allow</value>
|
||||
</field>
|
||||
<field var='vCard'>
|
||||
<value>Block</value>
|
||||
<value>block</value>
|
||||
</field>
|
||||
</x>
|
||||
</join>
|
||||
@ -1157,14 +1165,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
var='JID Visibility'>
|
||||
<option label='JID Never Shown'><value>Never</value></option>
|
||||
<option label='Default Behaviour'>
|
||||
<value>Default</value></option>
|
||||
<value>default</value></option>
|
||||
<option label='Try not to show JID'>
|
||||
<value>Prefer Not</value></option>
|
||||
<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>
|
||||
<option label='One Option'><value>a</value></option>
|
||||
<option label='Another Option'><value>b</value></option>
|
||||
</field>
|
||||
</x>
|
||||
</user-preference>
|
||||
@ -1184,13 +1192,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<field var='JID Visibility'>
|
||||
<value>Never</value>
|
||||
<value>never</value>
|
||||
</field>
|
||||
<field var='Private Messages'>
|
||||
<value>Allow</value>
|
||||
<value>allow</value>
|
||||
</field>
|
||||
<field var='vCard'>
|
||||
<value>Block</value>
|
||||
<value>block</value>
|
||||
</field>
|
||||
</x>
|
||||
</iq>
|
||||
@ -1205,13 +1213,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<field var='JID Visibility'>
|
||||
<value>Never</value>
|
||||
<value>never</value>
|
||||
</field>
|
||||
<field var='Private Messages'>
|
||||
<value>Allow</value>
|
||||
<value>allow</value>
|
||||
</field>
|
||||
<field var='vCard'>
|
||||
<value>Block</value>
|
||||
<value>block</value>
|
||||
</field>
|
||||
</x>
|
||||
</user-preference>
|
||||
@ -1480,7 +1488,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
id='kl2fax27'
|
||||
to='coven@mix.shakespeare.lit'
|
||||
type='get'>
|
||||
<pubsub xlns='http://jabber.org.protocol.pubsub'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:nodes:jidmap'>
|
||||
<item id='123456#coven@mix.shakespeare.example'/>
|
||||
</items>
|
||||
@ -1491,7 +1499,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
id='kl2fax27'
|
||||
to='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
type='result'>
|
||||
<pubsub xlns='http://jabber.org.protocol.pubsub'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:nodes:jidmap'>
|
||||
<item id='123456#coven@mix.shakespeare.example'>
|
||||
<participant xmlns='urn:xmpp:mix:0'
|
||||
@ -1691,7 +1699,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Inviting another User to join a Channel that the user does not have Permission to Join' anchor='usecase-user-invite'>
|
||||
<p> 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.
|
||||
<p> 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:
|
||||
|
||||
</p>
|
||||
@ -1704,7 +1712,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<li>The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.</li>
|
||||
</ol>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<example caption='Inviter Requests and Receives Invitation'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit/UUID-h5z/0253'
|
||||
@ -1810,7 +1818,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
|
||||
|
||||
<section3 topic="Requesting vCard" anchor="usecase-vcard">
|
||||
<p>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.</p>
|
||||
<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'
|
||||
|
||||
Loading…
Reference in New Issue
Block a user