1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00

corrected error in unique room name example

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@235 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-11-30 16:51:19 +00:00
parent 8e586c7f48
commit cd5d8ce572

View File

@ -3124,42 +3124,6 @@
</iq>
]]></example>
<p>The service MUST then unlock the room and allow other entities to join it.</p>
<section4 topic='Requesting a Unique Room Name' anchor='createroom-instant-unique'>
<p>In some situations (e.g., when <link url='#continue'>Converting a One-to-One Chat Into a Conference</link>), the room creator may want to request a unique room name before attempting to create the room (e.g., to avoid the possibility of a room conflict). In order to facilitate this, a service MAY support the feature described in this section. (If a service does support this feature, it MUST return a feature of "http://jabber.org/protocol/muc#unique" in its response to service discovery information requests.)</p>
<p>The room creator requests a unique room name by sending an IQ-get to the service itself, containing an empty &lt;unique/&gt; element qualified by the 'http://jabber.org/protocol/muc#unique' namespace:</p>
<example caption='Entity Requests Unique Room Name'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='unique1'
to='macbeth.shakespeare.lit'
type='get'>
<unique xmlns='http://jabber.org/protocol/muc#unique'/>
</iq>
]]></example>
<p>If the service supports this feature, it SHOULD return a unique room name as the XML character data of the &lt;unique/&gt; element:</p>
<example caption='Service Returns Unique Room Name'><![CDATA[
<iq from='macbeth.shakespeare.lit'
id='unique1'
to='crone1@shakespeare.lit/desktop'
type='result'>
<unique xmlns='http://jabber.org/protocol/muc#unique'>
6d9423a55f499b29ad20bf7b2bdea4f4b885ead1
</unique>
</iq>
]]></example>
<p>The service MAY refuse to return a unique room name to entities that are not entitled to create rooms, entities that have sent an excessive number of requests for unique room names, etc.</p>
<p>The service MAY use any algorithm that ensures the creation of a room name that will be permanently unique in the context of the service (e.g., a SHA-1 hash of the requesting JID, datetime, and random salt).</p>
<p>The room creator would then use the XML character data of the &lt;unique/&gt; element as the node identifier portion of the room JID it requests:</p>
<example caption='Owner Requests Instant Room'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='create1'
to='6d9423a55f499b29ad20bf7b2bdea4f4b885ead1@macbeth.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#owner'>
<x xmlns='jabber:x:data' type='submit'/>
</query>
</iq>
]]></example>
</section4>
</section3>
<section3 topic='Creating a Reserved Room' anchor='createroom-reserved'>
<p>If the initial room owner wants to create and configure a reserved room, the room owner MUST request an initial configuration form by sending an IQ get to the &ROOM; itself containing an empty &QUERY; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace:</p>
@ -3429,6 +3393,39 @@
<p>If the room owner cancels the initial configuration, the service SHOULD destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details).</p>
<p>If the room owner becomes unavailable for any reason before submitting the form (e.g., a lost connection), the service will receive a presence stanza of type "unavailable" from the owner to the owner's &ROOMJID; or to &ROOM; (or both). The service MUST then destroy the room, sending a presence stanza of type "unavailable" from the room to the owner including a &lt;destroy/&gt; element and reason (if provided) as defined in the <link url='#destroyroom'>Destroying a Room</link> section of this document.</p>
</section3>
<section3 topic='Requesting a Unique Room Name' anchor='createroom-unique'>
<p>In some situations (e.g., when <link url='#continue'>Converting a One-to-One Chat Into a Conference</link>), the room creator may want to request a unique room name before attempting to create the room (e.g., to avoid the possibility of a room conflict). In order to facilitate this, a service MAY support the feature described in this section. (If a service does support this feature, it MUST return a feature of "http://jabber.org/protocol/muc#unique" in its response to service discovery information requests.)</p>
<p>The room creator requests a unique room name by sending an IQ-get to the service itself, containing an empty &lt;unique/&gt; element qualified by the 'http://jabber.org/protocol/muc#unique' namespace:</p>
<example caption='Entity Requests Unique Room Name'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='unique1'
to='macbeth.shakespeare.lit'
type='get'>
<unique xmlns='http://jabber.org/protocol/muc#unique'/>
</iq>
]]></example>
<p>If the service supports this feature, it SHOULD return a unique room name as the XML character data of the &lt;unique/&gt; element:</p>
<example caption='Service Returns Unique Room Name'><![CDATA[
<iq from='macbeth.shakespeare.lit'
id='unique1'
to='crone1@shakespeare.lit/desktop'
type='result'>
<unique xmlns='http://jabber.org/protocol/muc#unique'>
6d9423a55f499b29ad20bf7b2bdea4f4b885ead1
</unique>
</iq>
]]></example>
<p>The service MAY refuse to return a unique room name to entities that are not entitled to create rooms, entities that have sent an excessive number of requests for unique room names, etc.</p>
<p>The service MAY use any algorithm that ensures the creation of a room name that will be permanently unique in the context of the service (e.g., a SHA-1 hash of the requesting JID, datetime, and random salt).</p>
<p>The room creator would then use the XML character data of the &lt;unique/&gt; element as the node identifier portion of the room JID it requests:</p>
<example caption='Owner Creates Room With Unique Name'><![CDATA[
<presence
from='crone1@shakespeare.lit/desktop'
to='6d9423a55f499b29ad20bf7b2bdea4f4b885ead1@macbeth.shakespeare.lit/firstwitch'>
<x xmlns='http://jabber.org/protocol/muc'/>
</presence>
]]></example>
</section3>
</section2>
<section2 topic='Subsequent Room Configuration' anchor='roomconfig'>
<p>At any time after specifying the initial configuration of the room, a room owner may want to change the configuration. In order to initiate this process, a room owner MUST request a new configuration form from the room by sending an IQ to &ROOM; containing an empty &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace.</p>