moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

Merge pull request #240 from SamWhited/xep0369_jid_format_fixes

Browse Source 
XEP-0369: Minor formatting and grammar fixes
This commit is contained in:
Kevin Smith 2016-09-01 11:40:11 +01:00 committed by GitHub
commit 4a3f7eb3a8
1 changed files with 24 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
xep-0369.xml
View File

@ -240,7 +240,7 @@
</section3>
<section3 topic="Presence Node" anchor="presence-node">
<p>
The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence message. The full JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control may be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza. The full JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control may be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
</p>
<p>QUESTION: The current specification allows channels to be configured so that node subscription is not restricted to participants (although this restriction is the default). Is this flexibility desirable, or should we restrict to participants?</p>
<p>
@ -497,7 +497,7 @@
id='5A9C7398-DB13-4BFA-A091-2D466C710AAF'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:mix:nodes:participants'>
<item id='123456@mix.shakespeare.example'>
<item id='coven+123456@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:0'
nick='thirdwitch'/>
</item>
@ -543,7 +543,7 @@
<message from='coven@mix.shakespeare.example' to='hecate@shakespeare.example' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:mix:nodes:participants'>
<retract id='123456@mix.shakespeare.example'/>
<retract id='coven+123456@mix.shakespeare.example'/>
</items>
</event>
</message>
@ -551,7 +551,7 @@
<message from='coven@mix.shakespeare.example' to='hecate@shakespeare.example' id='bar'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:mix:nodes:presence'>
<retract id='123456@mix.shakespeare.example/8765'/>
<retract id='coven+123456@mix.shakespeare.example/8765'/>
</items>
</event>
</message>
@ -567,7 +567,7 @@
<li>The nick is registered with the user account in some way, for example as part of user provisioning with nick configured as an attribute in a directory service. This may be chosen by corporate services that wish to ensure consistent nick values for a set of users and channels.</li>
<li>The nick is registered with the MIX service, as described in <link url='#usecase-user-register'> Registering a Nick </link>.</li>
<li>The user explicitly sets the nick, as described in this section.</li>
<li>The MIX service generates the nick. In this case it is recommended that the assigned nick is a UUID unique identifier following &rfc4122;. </li>
<li>The MIX service generates the nick. In this case it is recommended that the assigned nick is a UUID following &rfc4122;.</li>
</ol>
<p>AUTHOR'S NOTE AND QUESTION: REVIEW use of UUID. Can it make sense for other algorithms, such as a string from the JID</p>
<p>
@ -600,7 +600,7 @@
]]></example>
<section3 topic='Registering a Nick' anchor='usecase-user-register'>
<p>A user can register a nick with the MIX service. Nick registration can be used ensure that a user is able to use the same nick in all channels in the service and to prevent other users from using a registered nick. This can help achieve a consistent experience across a set of channels and prevent user confusion. Support for nick registration by a MIX service is optional. Where nick registration is supported, nick registration may be optional or mandatory.
Where a user has registered a Nick with the MIX service, it may be used by each channel according to policy for the channel. A Nick is associated with the user's bare JID.
Where a user has registered a Nick with the MIX service, it may be used by each channel according to policy for the channel. A nick is associated with the user's bare JID.
</p>
<p>
In order to determine if a Nick may be registered, the user may use disco to determine capabilities of the MIX service.
@ -642,8 +642,8 @@
</iq>
]]></example>
<p>If the requested nick is already taken, the MIX service returns a &lt;conflict/&gt; error:</p>
<example caption="Nick is Taken"><![CDATA[
<iq type='error'
<example caption="Nick is Taken">
<![CDATA[<iq type='error'
to='mix.shakespeare.example'
from='hag66@shakespeare.example/pda'
id='7nve413p'>
@ -652,7 +652,7 @@
</error>
</iq>
]]></example>
<p>If the register request does not contain a &lt;nick/&gt; element, then the MIX service assigns one. It is recommended that the assigned nick is a UUID unique identifier following &rfc4122;.
<p>If the register request does not contain a &lt;nick/&gt; element, then the MIX service assigns one. It is recommended that the assigned nick is a UUID following &rfc4122;.
</p>
@ -671,37 +671,35 @@
A channel may require that all channel members share presence information with the channel, which is represented in the "urn:xmpp:mix:nodes:presence" node. If sharing presences is required by the channel, an XMPP client conforming to this specification SHALL share presence with the channel by including the channel in the user's roster. Note that the MIX server cannot generally enforce this, but it can require and enforce that when a message is sent to the channel, that the sender of the message is in the presence list.
</p>
<p>
Presence status and availability is set in a MIX channel by standard presence messages sent to the MIX channel by the user's server. User's wishing to receive presence updates will subscribe to the MIX channel presence node. Presence updates are sent out to subscribing using standard XEP-0045 compatible presence messages.
Presence status and availability is set in a MIX channel by standard presence stanzas sent to the MIX channel by the user's server. User's wishing to receive presence updates will subscribe to the MIX channel presence node. Presence updates are sent out to subscribing using standard XEP-0045 compatible presence stanzas.
</p>
<p>
A user setting status is now used as an example. Unlike in &xep0045; where coming online is a special action, coming online in MIX is implicit when presence status is set. Going offline is a achieved by setting presence status to unavailable, which removes the client full JID entry from the presence node. When a user sets a presence status, the user's server sends updated presence to the MIX channel, and the MIX server then publishes the user's availability to the "urn:xmpp:mix:nodes:presence" node. If there is not an item named by the full JID of the client with updated presence status, this item is created. If there is not an item named by the full JID of the client with updated presence status, then an item is created.</p>
<example caption="User Setting Presence Status"><![CDATA[
<presence xmlns='jabber:client' from=‘hag66@shakespeare.example/pda’ to='coven@mix.shakespeare.example'>
<example caption="User Setting Presence Status">
<![CDATA[<presence xmlns='jabber:client' from=‘hag66@shakespeare.example/pda’ to='coven@mix.shakespeare.example'>
<show>dnd</show>
<status>Making a Brew</status>
</presence>
]]></example>
<p>The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID. The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence message is sent from the proxy (anonymized) full JID of the user. </p>
<example caption="Channel Distributes Presence"><![CDATA[
<presence from='coven+123435@mix.shakespeare.example/678'
</presence>]]></example>
<p>The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID. The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the proxy (anonymized) full JID of the user. </p>
<example caption="Channel Distributes Presence">
<![CDATA[<presence from='coven+123435@mix.shakespeare.example/678'
to='coven@mix.shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
<nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
<show>dnd</show>
<status>Making a Brew</status>
</presence>
]]></example>
</presence>]]></example>
<p>
The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence message. The presence change is recorded on the "urn:xmpp:mix:nodes:presence" node in the item for the full JID of the client to which the presence relates. The history of this node will be held as PubSub format in the MAM archive, so that presence history may be viewed.
The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence stanza. The presence change is recorded on the "urn:xmpp:mix:nodes:presence" node in the item for the full JID of the client to which the presence relates. The history of this node will be held as PubSub format in the MAM archive, so that presence history may be viewed.
</p>
</section3>
<section3 topic="Coming Online: Obtaining Presence" anchor="usecase-obtaining-presence">
<p>
The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence messages to users subscribing to this presence node. The user's server will then pass this presence information on to all online clients. When a client goes offline, it will lose synchronization with the presence node. When the client comes online, the clients server will send a directed presence message to the MIX channel. This will happen as a consequence of the MIX channel being in the user's roster and the MIX channel sending a presence update to the MIX channel. When the MIX channel adds or modifies presence for a client to the roster, this presence change will be distributed to all users subscribing to the presence node.
The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to users subscribing to this presence node. The user's server will then pass this presence information on to all online clients. When a client goes offline, it will lose synchronization with the presence node. When the client comes online, the clients server will send a directed presence stanza to the MIX channel. This will happen as a consequence of the MIX channel being in the user's roster and the MIX channel sending a presence update to the MIX channel. When the MIX channel adds or modifies presence for a client to the roster, this presence change will be distributed to all users subscribing to the presence node.
</p>
<p>
When the full JID of a client is added to the MIX channel presence node and that full JID is not in the presence list, the MIX channel will send to the client presence for all of the items in the presence node using standard presence messages. This will give the client full current presence.
When the full JID of a client is added to the MIX channel presence node and that full JID is not in the presence list, the MIX channel will send to the client presence for all of the items in the presence node using standard presence stanzas. This will give the client full current presence.
</p>
</section3>
@ -732,13 +730,12 @@
from='hag66@shakespeare.example/pda'
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 using a presence message from the proxy JID of the client.</p>
<example caption="Channel Distributes Notification of Client going Offline"><![CDATA[
<presence from='coven+12345@mix.shakespeare.example/678'
<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 using a presence stanza from the proxy JID of the client.</p>
<example caption="Channel Distributes Notification of Client going Offline">
<![CDATA[<presence from='coven+12345@mix.shakespeare.example/678'
to='hecate@shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='unavailable'/>
]]></example>
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 server may take steps to address this, for example by probing client with a disco for presence items that remain unchanged for a long period.