%ents; ]>
Hats This specification defines a more extensible model for roles and affiliations in Multi-User Chat rooms. &LEGALNOTICE; 0317 Deferred Standards Track Standards Council XMPP Core XEP-0045 XEP-0050 NOT_YET_ASSIGNED &stpeter; 0.1 2013-01-03 psa

Initial published version approved for publication by the XMPP Council; clarified ad-hoc commands logic and syntax.

 0.0.2 2012-12-09 psa

Described use of ad-hoc commands for adding and removing hats.

 0.0.1 2012-12-06 psa

First draft.

&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.

A MUC service that supports hats MUST advertise a &xep0030; feature of "urn:xmpp:hats:0".

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.

]]>

Note: The format is open for debate. Possibilities include:

  1. XML element in the hats namespace with name as a URI:

    <hat xmlns='urn:xmpp:hats:0' name='http://tech.example.edu/hats#TeacherAssistant' display='Teacher&apos;s Assistant' xml:lang='en-us'/>

    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.

    Con: Not a very Jabberish way of structuring information.

  2. XML element in the hats namespace with name scoped using Clark Notation:

    <hat xmlns='urn:xmpp:hats:0' name='{http://tech.example.edu/hats}TeacherAssistant' display='Teacher&apos;s Assistant' xml:lang='en-us'/>

    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.

    Con: Not a very Jabberish way of structuring information.

  3. XML element qualified by custom namespace:

    <TeacherAssistant xmlns='http://tech.example.edu/hats' displayname='Teacher&apos;s Assistant' xml:lang='en-us'/>

    Pro: A more Jabberish way to structure information.

    Con: Clients won't show anything if they don't understand the custom namespace.

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.

]]>

Hats are added and removed using &xep0050;.

The following flow shows how to add a hat.

]]>

Unless an error occurs, the service returns the appropriate form.

Assigning a Hat Fill out this form to assign a hat. urn:xmpp:hats:commands ]]> urn:xmpp:hats:commands terry.anderson@example.edu http://tech.example.edu/hats#TeacherAssistant ]]> ]]>

Note: only one hat is added at a time, and the form uses a field of type "list-single" to enforce that logic.

The following flow shows how to remove a hat.

urn:xmpp:hats:commands terry.anderson@example.edu ]]> ]]>

To follow.

This document requires no interaction with &IANA;.

The XMPP Registrar shall add "urn:xmpp:hats:0" to its registry of protocol namespaces.

To follow.

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.