%ents; ]>
User Mood This specification defines a payload format for communicating information about user moods, such as whether a person is currently happy, sad, angy, or annoyed. The payload format is typically transported using the personal eventing profile of XMPP publish-subscribe as specified in XEP-0163. &LEGALNOTICE; 0107 Draft Standards Track Standards XMPP Core XEP-0163 mood http://www.xmpp.org/schemas/mood.xsd &stpeter; &ralphm; 1.1 2007-06-04 psa

Corrected PEP examples.

1.0 2004-10-20 psa/rm

Per a vote of the Jabber Council, advanced status to Draft; per Council discussion, also added two additional moods and adjusted structure to use elements rather than XML character data.

0.6 2004-09-15 psa

Added internationalization considerations.

0.5 2004-04-25 psa

Corrected several errors; added reference to XEP-0033.

0.4 2004-02-19 psa

Minor fixes to text and schema.

0.3 2003-08-01 psa

Added more moods.

0.2 2003-07-23 psa

Expanded the information format; changed primary container to use pubsub.

0.1 2003-07-22 psa

Initial version.

This document defines an extension mechanism for capturing "extended presence" data about user moods.

Information about user moods is provided by the user and propagated on the network by the user's client. The information is structured via a <mood/> element that is qualified by the 'http://jabber.org/protocol/mood' namespace. The mood itself is provided as the element name of a defined child element of the <mood/> element (e.g., <happy/>); one such child element is REQUIRED. The user MAY also specify a natural-language description of, or reason for, the mood in the <text/> child of the <mood/> element, which is OPTIONAL. Here is an example:

Yay, the mood spec has been approved! ]]>

In addition, an application MAY provide a more specific mood value as a properly-namespaced child of the defined element, which extension MUST be ignored if the receiving application does not understand the extended namespace. Here is an example:

Yay, the mood spec has been approved! ]]>

Mood information SHOULD be communicated and transported by means of the &xep0060; subset specified in &xep0163;. Because mood information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.

curse my nurse! ]]>

The mood is then delivered to all subscribers:

curse my nurse! . . . ]]>

A user MAY provide a mood extension in a specific message in order to lend a defined emotional tone to the text.

A thousand times good night! ]]>

There exist various theories of human affect, mood, and emotion, including those promulgated by Frijda Frijda, N. 1986. The Emotions. New York: Cambridge University Press., Ortony et al. Ortony, A., Clore, G., and Collins, A. 1988. The Cognitive Structure of Emotions. Hillsdale, NJ: Erlbaum., and Wierzbicka Wierzbicka, A. 1992. Defining Emotion Concepts. Cognitive Science 16: 539-581.. The taxonomy provided here mostly follows the Affective Knowledge Representation that has been defined by Lisetti Lisetti, C. 2002. Personality, Affect, and Emotion Taxonomy for Socially Intelligent Agents. In Proceedings of FLAIRS 2002. Menlo Park, CA: AAAI Press. in an effort to harmonize the prevailing theories in this area, as well as some work by Wierzbicka on cross-cultural studies of emotion. Wierzbicka, A. 1999. Emotions across Languages and Cultures. Cambridge: Cambridge University Press. Furthermore, the taxonomy provided here includes a number of common physical states in addition to moods, and also takes into account the specific context of instant messaging, including work done by other standards development organizations (e.g., the Wireless Village specifications contributed to the &OMA;) and instant messaging service providers (e.g., ICQ). Finally, lists of moods and physical states have been checked for commonality against studies of word frequency in the English language Leech, G., Rayson, P., and Wilson, A. 2001. Word Frequencies in Written and Spoken English. Harlow, England: Pearson Education. to remove rarely used terms.

The mood values defined in this taxonomy are as follows:

The Wireless Village (now "IMPS") specifications for mobile instant messaging define a number of presence attributes, encapsulated in the "StatusMood" information element The Wireless Village Initiative: Presence Attributes v1.1 (WV-029); for further information, visit <http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html>.. The following values are defined for StatusMood in Wireless Village, all of which map one-to-one from Wireless Village to the same values (albeit lowercase) in Jabber:

The full range of moods defined herein is richer than that defined in Wireless Village; no mapping is provided by this specification for mood values that are not present in Wireless Village, and any such mapping is the responsibility of a gateway between the two systems.

The XML character data values of the <value/> elements is not intended to be presented to a human user and thus there is no special reason to include an 'xml:lang' attribute unless the sender includes a <text/> element as well (as explained in &rfc2277;, "internationalization is for humans"). It is the responsibility of the receiving application to provide localized text strings associated with the XML character data values defined herein, or some other appropriate presentation (e.g., graphical images that represent the mood).

Because user moods may be published to a large number of pubsub subscribers, users should take care in approving subscribers and in characterizing their current moods.

This document requires no interaction with &IANA;.

The ®ISTRAR; includes 'http://jabber.org/protocol/mood' in its registry of protocol namespaces.

]]>