Corrected PEP examples.
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.
Added internationalization considerations.
Corrected several errors; added reference to XEP-0033.
Minor fixes to text and schema.
Added more moods.
Expanded the information format; changed primary container to use pubsub.
Initial version.
Yay, the mood document has been approved!
+ 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:
@@ -86,21 +92,19 @@The <mood/> element SHOULD be communicated by means of &xep0060; or the subset of publish-subscribe specified in &xep0163;, but MAY be provided in a message as well. 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;.
-If the user wishes to publish his mood to all of those who are subscribed to his mood information, the user SHOULD use publish-subscribe (the following examples show use of the publish-subscribe subset specified in XEP-0163).
+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;.
The mood is then delivered to all subscribers:
As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:
-A user MAY also provide a mood extension in a specific message, in order to lend a defined emotional tone to the message.
+A user MAY provide a mood extension in a specific message in order to lend a defined emotional tone to the text.
The <mood/> element could even contain a URL reference structured according to the &xep0066; protocol:
-Corrected PEP examples.
Per a vote of the Jabber Council, advanced status to Draft; per Council discussion, also adjusted structure to use nested elements rather than XML character data.
Added internationalization considerations.
Corrected several errors; added reference to XEP-0033.
Minor text and schema changes; added RPID mapping.
Initial version.
In accordance with &xmppcore;, the receiving application MUST ignore a specific activity element or detailed activity element if it does not understand the namespace that qualifies the element.
The <activity/> element SHOULD be communicated by means of &xep0060; or the subset of publish-subscribe specified in &xep0163;. Because activity 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;.
-Note: The following examples show use of the publish-subscribe subset specified in XEP-0163.
+Activity information SHOULD be communicated and transported by means of the &xep0060; subset specified in &xep0163;. Because activity 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;.
The activity is then delivered to all subscribers:
As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:
-Removed non-PEP examples; added uri element.
Per a vote of the Jabber Council, advanced status to Draft.
Added example with URL.
Changed recommendation to not include the <length/> element if the track time is unknown.
Added implementation notes; clarified nature of <source/> and <track/> elements; if length is unknown, set to zero.
Changed <length/> datatype from xs:duration to xs:unsignedShort.
Corrected several errors; added reference to XEP-0033.
Reverted from infobits to tune elements.
Slight modifications to track changes to infobits specifications.
Replaced tune elements with infobits.
Added "stop" function via empty <tune/> element.
Initial version.
NOTE: The datatypes specified above are defined in &w3xmlschema2;.
Tune information SHOULD be communicated and transported by means of the &xep0060; protocol or the subset of publish-subscribe specified in &xep0163;. Because tune 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;.
-Note: The following examples show use of the publish-subscribe subset specified in XEP-0163.
+Tune information SHOULD be communicated and transported by means of the &xep0060; subset specified in &xep0163;. Because tune 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;.
The tune information is then delivered to all subscribers:
As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:
-Naturally, further extensions could be included, e.g., using &xep0066; to specify a URL where one could buy the recording.
-In order to indicate that the user is no longer listening to any tunes, the user's client SHOULD send an empty <tune/> element, which can be considered a "stop command" for user tunes:
To prevent a large number of updates when a user is skipping through tracks, an implementation may wait several seconds before publishing new tune information.
+To prevent a large number of updates when a user is skipping through tracks, an implementation SHOULD wait several seconds before publishing new tune information.
If the length is unknown (e.g., the user is listening to a stream), the <length/> element SHOULD NOT be included.