<remark><p>Described use of ad-hoc commands for adding and removing hats.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2012-12-06</date>
<initials>psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&xep0045; defines a widely-implemented XMPP extension for chatrooms, including basic roles and affiliations such as owner, administrator, and moderator. However, in many scenarios it is desirable to define different roles that are appropriate for the relevant application. Examples might include a "presenter" or a "scribe" in an online meeting system, a "representative" or a "manager" in a customer service application, a "comms officer" in a military chat system, an "incident manager" in a first responder system, a "teacher" or a "teacher's assistant" in an online classroom, specialized roles in online games, etc. To prevent confusion with standard MUC roles, these extended roles are call "hats", since a participant can "wear many hats" in a room.</p>
</section1>
<section1topic='Discovery'anchor='disco'>
<p>A MUC service that supports hats MUST advertise a &xep0030; feature of "urn:xmpp:hats:0".</p>
</section1>
<section1topic='Protocol'anchor='protocol'>
<section2topic='Including a Hat in Presence'anchor='presence'>
<p>MUC already includes a way for the room to signal the roles and affiliations of room occupants. Hats are signalled in a similar way. For example, the following presence notification would be sent by the room for an occupant who is a MUC room moderator but who also has a hat of "teacher's assistant" in an online classroom.</p>
<p>Pro: Clients that don't understand the 'http://tech.example.edu/hats#TeacherAssistant' semantics can at least display a human-readable name. Names can be registered with the XMPP Registrar. Also appropriate as a field name in Ad-Hoc Commands.</p>
<p>Con: Not a very Jabberish way of structuring information.</p>
</li>
<li>
<p>XML element in the hats namespace with name scoped using Clark Notation:</p>
<p>Pro: Clients that don't understand the 'http://tech.example.edu/hats#TeacherAssistant' semantics can at least display a human-readable name. Names can be registered with the XMPP Registrar. Also integrates well with Ad-Hoc Commands.</p>
<p>Con: Not a very Jabberish way of structuring information.</p>
<p>As noted, a participant can wear many hats. The following example shows a participant who is a MUC room owner and both a "host" and a "presenter" in an online meeting system.</p>
<examplecaption='Presence With Multiple Hats'><![CDATA[
<p>The concepts underlying this specification were first discussed several years ago at an XMPP Summit in Brussels, Belgium. Special thanks to Joe Hildebrand and Ralph Meijer for their contributions to those discussions. Thanks also to Matt Miller, Kevin Smith, and Matthew Wild for their feedback on the written specification.</p>