mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
MIX: Correct indentation, sentences and examples
This commit is contained in:
Melvin Keskin
parent
48018afe1b
commit
e82b0f054d
@ -1007,7 +1007,7 @@
|
||||
<section2 topic='Common User Use Cases' anchor='usecases-user'>
|
||||
<section3 topic="Model for Join and Leave" anchor="usecase-jl-model">
|
||||
<p>
|
||||
MIX Join and Leave communication goes through the clients server. The full specification of client interaction with the client's server is specified in MIX-PAM. This specification shows the protocol between the user's server and the MIX server and sets out behaviour of the MIX server.
|
||||
MIX Join and Leave communication goes through the client's server. The full specification of client interaction with the client's server is specified in MIX-PAM. This specification shows the protocol between the user's server and the MIX server and sets out behaviour of the MIX server.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Joining a Channel' anchor='usecase-user-join'>
|
||||
@ -1116,11 +1116,11 @@
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>
|
||||
A user MAY specify a nick when joining the channel. Channels MAY have mandatory nicks, which is default behavior. Therefore it will generally be necessary to include a nick when joining an channel. If nick is missing on a channel where nick is mandatory, the join MUST be rejected. Other error cases are dealt with below with the nick management commands. Where a nick is specified, the join will only complete if the nick is accepted. The nick used MUST be reported back in the join result.
|
||||
A user MAY specify a nick when joining the channel. Channels MAY have mandatory nicks, which is default behavior. Therefore it will generally be necessary to include a nick when joining a channel. If nick is missing on a channel where nick is mandatory, the join MUST be rejected. Other error cases are dealt with below with the nick management commands. Where a nick is specified, the join will only complete if the nick is accepted. The nick used MUST be reported back in the join result.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Leaving a Channel' anchor='usecase-user-leaving'>
|
||||
<p>Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The following example shows a leave request to a MIX channel. </p>
|
||||
<p>Users generally remain in a channel for an extended period of time. In particular the user remains as a participant of the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The following example shows a leave request to a MIX channel. </p>
|
||||
<example caption="User's Server sends Leave Request to a Channel"><![CDATA[
|
||||
<iq type='set'
|
||||
from='hag66@shakespeare.example'
|
||||
|
||||
@ -506,7 +506,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</section2>
|
||||
|
||||
<section2 topic="MIX Roster Item Capability Sharing" anchor="mix-roster-capability-sharing">
|
||||
<p>It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.</p>
|
||||
<p>It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server returns this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.</p>
|
||||
<example caption="Roster Get Requesting MIX Information"><![CDATA[
|
||||
<iq from='juliet@example.com/balcony'
|
||||
id='bv1bs71f'
|
||||
|
||||
@ -218,7 +218,7 @@
|
||||
</section1>
|
||||
<section1 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 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:
|
||||
When a channel participant (the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:
|
||||
|
||||
</p>
|
||||
<ol>
|
||||
@ -230,7 +230,7 @@
|
||||
<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 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. The invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:misc:0' namespace. <invite/> contains an <invitation/> child element, which contain <inviter/>, <invitee/>, <channel/> and <token/> child elements.
|
||||
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. The invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:misc:0' namespace. <invite/> contains an <invitation/> child element, which contains <inviter/>, <invitee/>, <channel/> and <token/> child elements.
|
||||
</p>
|
||||
<example caption='Inviter Requests and Receives Invitation'><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/UUID-h5z/0253'
|
||||
@ -264,14 +264,14 @@
|
||||
<message from='hag66@shakespeare.example/UUID-h5z/0253'
|
||||
id='f5pp2toz'
|
||||
to='cat@shakespeare.example'>
|
||||
<body>Would you like to join the coven?<body>
|
||||
<body>Would you like to join the coven?</body>
|
||||
<invitation xmlns='urn:xmpp:mix:misc:0'>
|
||||
<inviter>hag66@shakespeare.example</inviter>
|
||||
<invitee>cat@shakespeare.example</invitee>
|
||||
<channel>coven@mix.shakespeare.example</channel>
|
||||
<token>ABCDEF</token>
|
||||
</invitation>
|
||||
</iq>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>The invitation can now be used by the invitee to join a channel. The <invitation/> child element is simply added to the standard channel <join/> element, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.</p>
|
||||
<example caption="User Joins a Channel with an Invitation"><![CDATA[
|
||||
|
||||
Loading…
Reference in New Issue
Block a user