<p>&xep0045; defines the protocol for groupchat in XMPP. In some situations, 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). Naturally, one way to do so is for the creator's client to generate a globally unique identifier, for example as defined in &rfc4122;. Another way is for the client to ask the MUC service for a unique room ID (which the service will thus reserve for that user).</p>
</section1>
<section1topic='Protocol'anchor='proto'>
<p>The room creator requests a unique room name by sending an IQ-get to the service itself, containing an empty <unique/> element qualified by the 'http://jabber.org/protocol/muc#unique' namespace:</p>
<p>If the service supports this feature, it SHOULD return a unique room name as the XML character data of the <unique/> element (but not create the room):</p>
<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 cryptographic hash of the requesting JID, datetime, and random salt), or simply use a UUID as defined by <cite>RFC 4122</cite>.</p>
<p>The room creator would then use the XML character data of the <unique/> element as the node identifier portion of the room JID it requests:</p>
<examplecaption='Owner Creates Room With Unique Name'><![CDATA[
<p>If a MUC service supports the protocol specified herein, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/muc#unique" in response to &xep0030; information requests &NSNOTE;.</p>
<examplecaption="Service discovery information request"><![CDATA[