%ents; ]>
User Tune This document defines an XMPP protocol extension for communicating information about the music to which a user is listening. &LEGALNOTICE; 0118 Draft Standards Track Standards XMPP Core XEP-0163 tune http://www.xmpp.org/schemas/tune.xsd &stpeter; 1.1 2007-06-04 psa

Removed non-PEP examples; added uri element.

 1.0 2004-11-12 psa

Per a vote of the Jabber Council, advanced status to Draft.

 0.10 2004-10-29 psa

Added example with URL.

 0.9 2004-10-27 psa

Changed recommendation to not include the <length/> element if the track time is unknown.

 0.8 2004-10-26 psa

Added implementation notes; clarified nature of <source/> and <track/> elements; if length is unknown, set to zero.

 0.7 2004-05-20 psa

Changed <length/> datatype from xs:duration to xs:unsignedShort.

 0.6 2004-04-25 psa

Corrected several errors; added reference to XEP-0033.

 0.5 2004-02-19 psa

Reverted from infobits to tune elements.

 0.4 2003-12-14 psa

Slight modifications to track changes to infobits specifications.

 0.3 2003-10-23 psa

Replaced tune elements with infobits.

 0.2 2003-09-10 psa

Added "stop" function via empty <tune/> element.

 0.1 2003-09-08 psa

Initial version.

This document defines a protocol for communicating information about the music to which a user is listening. Such information may be seen as a kind of "extended presence", and users may want to communicate such information to their contacts on the network as a fun add-on to traditional IM applications or to provide integration with common music-player applications.

Information about tunes is provided by the user and propagated on the network by the user's client. The information container for tune data is a <tune/> element that is qualified by the 'http://jabber.org/protocol/tune' namespace. The tune information itself is provided as the XML character data of the following children of the <tune/> element:

Element Description Example Datatype
artist The artist or performer of the song or piece Yes xs:string
length The duration of the song or piece in seconds 686 xs:unsignedShort
source The collection (e.g., album) or other source (e.g., a band website that hosts streams or audio files) Yessongs xs:string
title The title of the song or piece Heart of the Sunrise xs:string
track A unique identifier for the tune; e.g., the track number within a collection or the specific URI for the object (e.g., a stream or audio file) 3 xs:string
uri A URI or URL pointing to information about the song, collection, or artist http://www.yesworld.com/lyrics/Fragile.html#9 xs:anyURI

NOTE: The datatypes specified above are defined in &w3xmlschema2;.

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

Yes 686 Yessongs Heart of the Sunrise 3 http://www.yesworld.com/lyrics/Fragile.html#9 ]]>

The tune information is then delivered to all subscribers:

Yes 686 Yessongs Heart of the Sunrise 3 http://www.yesworld.com/lyrics/Fragile.html#9 . . . ]]>

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

This protocol introduces no security considerations above and beyond those defined in Publish-Subscribe (XEP-0060).

This document requires no interaction with &IANA;.

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

 The protocol documented by this schema is defined in XEP-0118: http://www.xmpp.org/extensions/xep-0118.html ]]>