path: root/ytstenut-protocol.xml

<?xml version="1.0" encoding="utf-8"?>
<article xmlns="http://docbook.org/ns/docbook" version="5.0"
	 xmlns:xi="http://www.w3.org/2001/XInclude"
	 xmlns:xlink="http://www.w3.org/1999/xlink"
	 xml:id="ytstenut-protocol" xml:lang="en" class="specification"
	 status="draft">
  <info>

    <title>Ytstenut Protocol Specification</title>
	<subtitle>Version 0.2</subtitle>

	<org>
	  <orgname>Intel Corporation</orgname>
	  <orgdiv>Open Source Technology Centre</orgdiv>
	</org>

    <author>
      <personname>
	<firstname>Tomas</firstname> <surname>Frydrych</surname>
<!--
      <affiliation>
        <orgname>Intel Corporation</orgname>
      </affiliation>
-->
      </personname>
      <email>tf@linux.intel.com</email>
    </author>

    <revhistory>
<!--
      <revision>
         <revnumber>0.1</revnumber>
         <date>22 October 2010</date>
         <revremark>Initial draft</revremark>
      </revision>
      <revision>
         <revnumber>0.2</revnumber>
         <date>27 October 2010</date>
         <revremark>
	   responding to comments from Will Thompson (Collabora)
	 </revremark>
      </revision>
      <revision>
         <revnumber>0.3</revnumber>
         <date>29 October 2010</date>
         <revremark>
	   tidying up loose ends
	 </revremark>
      </revision>
-->
      <revision>
         <revnumber>0.4</revnumber>
         <date>1 November 2010</date>
         <revremark>
	   Initial draft
	 </revremark>
      </revision>
      <revision>
         <revnumber>0.5</revnumber>
         <date>29 November 2010</date>
         <revremark>
	   Changed JID specification; use XEP-0050 as messaging backbone
	 </revremark>
      </revision>
      <revision>
         <revnumber>0.6</revnumber>
         <date>30 November 2010</date>
         <revremark>
	   General edits.
	 </revremark>
      </revision>

      <revision>
         <revnumber>0.7</revnumber>
         <date>15 December 2010</date>
         <revremark>
	   Improvements to Introduction, diagrams
	 </revremark>
      </revision>

      <revision>
         <revnumber>0.8</revnumber>
         <date>24 January 2011</date>
         <revremark>
	   Initial update to use XPMN backbone
	 </revremark>
      </revision>

      <revision>
         <revnumber>0.9</revnumber>
         <date>24 January 2011</date>
         <revremark>
	   Not using Ad-Hoc
	 </revremark>
      </revision>

      <revision>
         <revnumber>0.10</revnumber>
         <date>22 February 2011</date>
         <revremark>
	   Fix cap advertisement
	 </revremark>
      </revision>

    </revhistory>

    <copyright>
      <year>2011</year>
      <holder>Intel Corporation</holder>
    </copyright>
  </info>

<?hard-pagebreak?>

  <section xml:id="intro">
    <title>Introduction</title>
    <para>
      We often carry out similar activities on different devices, e.g., watch
      videos on a smart phone, laptop, or a TV set. However, as we move in time
      and space, the optimal choice of a device for any given activity changes:
      a smart phone might be the perfect video viewing platform while travelling
      on a train, but a TV set might be preferred in the comfort of one's living
      room.
    </para>

    <para>
      Furthermore, our discrete activities are often interconnected even when
      distributed across distinct devices: a person watching a TV might
      want to locate some additional information about the broadcast (e.g.,
      who the director is, special effects details, etc.), and might use a
      smart phone, rather than the TV, to search for it.
    </para>

    <para>
      The above examples illustrate two key aspects of human interaction with
      today's technology: (a) our activities are no longer confined to a single
      dedicated device each, but are distributed over a device mesh, and (b) the
      mesh as a whole now provides a context which shapes the activities
      themselves.
    </para>

    <para>
      Unfortunately, the technologies of today neither allow for our experience
      to stretch seamlessly over the device mesh, nor provide an easy access to
      the unified activity context the device mesh represents.  What device
      meshing technologies there already are (e.g., UPnP), tend to focus
      narrowly on the sharing of hardware resources. While resource sharing is
      an important capability of the device mesh, on it's own it only provides a
      quantitative, rather than qualitative, improvement on the overall user
      experience (e.g., the ability to use a TV set to watch a video
      stored on a PC does not represent a radical improvement on using a memory
      stick to achieve the same).
    </para>

    <para>
      A radical improvement of the user experience requires to be able not just
      to share resources between devices, but to be able to share, and to
      interact with, the user activities per se, and do so across the device
      mesh in a seamless fashion. And since user activities are generally mapped
      directly to user facing applications, what is in fact needed is an
      application mesh facilitating both active interaction and passive mutual
      awareness between applications.
    </para>

    <para>
      The Ytstenut framework aims to facilitate the creation of a such a dynamic
      application mesh. It does so by providing a communication channels through
      which individual user-facing applications on distinct devices can
      passively advertise their activities in real time, and actively cooperate
      and coordinate their discrete behaviours, and in so construct a dynamic
      and homogeneous experience spanning the devices involved.
    </para>

    <para>
      The activities for which consumers use computers are impossible to
      enumerate, and are set to evolve. Consequently the Ytstenut framework does
      not seek to narrowly define the activities and/or services that might fall
      withing its scope, nor it seeks to prescribe the ways in which such
      activities or tasks should be accomplished. Rather the Ytstenut framework
      is a set of generic protocols that can support new activities and services
      without the need to modify the core protocols.
    </para>

    <para>
      More specifically, the aims of the Ytstenut framework are as follows:
    </para>

    <itemizedlist>
      <listitem>
	<para>
	  To provide unified discovery, connection and transport mechanism that
	  could be utilised by user-facing applications running on a variety of
	  hardware and software platforms,
	</para>
      </listitem>

      <listitem>
	<para>
	  To provide standardised metadata model to facilitate efficient
	  inter-application communication,
	</para>
      </listitem>

      <listitem>
	<para>
	  To provide mechanisms for both active interaction between
	  applications, and passive awareness of each other.
	</para>
      </listitem>
    </itemizedlist>

    <section xml:id="intro-big-picture">
      <title>The Big Picture</title>

      <figure xml:id="fig-two-app-mesh">
	<title>Two-application mesh</title>
	<mediaobject>
	  <imageobject>
	    <imagedata align="center" width="95%"
		       fileref="images/basic_structure.svg"/>
	  </imageobject>
	</mediaobject>
      </figure>

      <para>
	The preceding diagram outlines a Ytstenut mesh consisting of two
	applications on two devices. Note the separation between the metadata
	and status channel, provided by the Ytstenut framework, and the actual
	content data transfer, which is happening outwidth the framework, and
	relies on other industry standards.
      </para>

      <para>
	The Ytstenut mesh, may, of course consist of any number of
	applications, on any number of devices (potentially with multiple
	applications on any single device). The possible topologies of the mesh
	are described in the following section.
      </para>

    </section>

    <section xml:id="intro-topologies">
      <title>Ytstenut Mesh Topologies</title>

      <para>
	The application mesh established through the Ytstenut framework can have
	two basic topologies: server-centric, and server-less home cloud. The
	Ytstenut framework aims to support both of these scenarios in a
	transparent manner, and it is possible that additional mesh topologies
	will be facilitated in future versions of this protocol.
      </para>

      <section xml:id="intro-topologies-server">
	<title>Server-based Mesh</title>

      <figure xml:id="fig-two-server-mesh">
	<title>Server mesh</title>
	<mediaobject>
	  <imageobject>
	    <imagedata align="center" width="95%"
		       fileref="images/server_mesh.svg"/>
	  </imageobject>
	</mediaobject>
      </figure>

	<para>
	  In a server-based mesh applications communicate with each other via a
	  central server (NB: only metadata and status information is passed
	  through the server; content is passed out of band). This type of mesh
	  provides two principal benefits: it places no requirements on the
	  topology of the underlying network, and it gives the server operator
	  complete control over access and services on offer. As such, the
	  server-based mesh is well suited, for example, for subscription
	  services.
	</para>

      </section>

      <section xml:id="intro-topologies-cloud">
	<title>LAN-based Cloud Mesh</title>

      <figure xml:id="fig-two-cloud-mesh">
	<title>Cloud mesh</title>
	<mediaobject>
	  <imageobject>
	    <imagedata align="center" width="95%"
		       fileref="images/cloud_mesh.svg"/>
	  </imageobject>
	</mediaobject>
      </figure>

	<para>
	  The LAN-based cloud mesh differs from server-based mesh by the absence
	  of a central server; instead applications are able to discover each
	  other, and communicate, transparently throughout the cloud. The main
	  benefit of the LAN-based cloud is eliminating the need for operating
	  and administrating a server; as such this type of mesh is particularly
	  suited for the domestic use case.
	</para>

      </section>

    </section>

    <section xml:id="intro-application-classes">
      <title>Application Classes</title>

      <para>
	Ytstenut applications can be divided into two broad classes:

	<itemizedlist>
	  <listitem>
	    <para>
	      Task-oriented applications: these are the core participants in the
	      Ytstenut mesh. They are user-facing applications, such as media
	      players, that have been enriched by adding the Ytstenut
	      capabilities.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Control Applications: these provide background Ytstenut services on
	      an Ytstenut-enabled devices. Their principal purpose is to allow
	      task-oriented applications to direct their communications at a
	      device, rather than a specific task-oriented application on that
	      device, and to ensure that appropriate task-oriented application
	      is available (e.g., by spawning of suitable application on the
	      device in response to incoming requests).
	    </para>

	    <para>
	      While control applications can be purely background processes,
	      when provided with a suitable UI they can be used as generic
	      Ytstenut remote controls.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>
    </section>

    <section xml:id="intro-metadata">
      <title>Metadata model</title>

      <para>
	One of the key components of the Ytstenut framework is the metadata
	model. The purpose of the Ytstenut protocols is to allow applications to
	exchange metadata describing their activities in a way that would allow
	them to coordinate these across multiple devices and
	platforms. Consequently, the metadata model must be:

	<itemizedlist>
	  <listitem>
	    <para>
	      Flexible and extensible, to allow use with new, innovative
	      applications,
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Sufficiently standardised to allow common classes
	      of applications to talk to each other transparently.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	It is worth noting that the protocol does not aim to provide mechanisms
	for actual data transfers, though in some common and specific cases it
	mandates which other standard protocols should be used (see <xref
	linkend="messaging-data-transfer"/>).
      </para>

      <para>
	The Ytstenut metadata is modelled as a pairing of a capability subject
	(representing a single application feature that is of interest to a
	user) and an activity predicate (a way in which the user can manipulate
	content tied to a specific capability). Both the capability and the
	activity in each specific pair can be further qualified by attributes;
	the resulting <code>{capability, activity, attributes}</code> tuple
	constitutes the elementary unit of Ytstenut metadata.
      </para>

      <para>
	The above described tuple is used in two distinct ways: to indicate
	present application state, and to encapsulate instructions about future
	desired state.
      </para>

      <para>
	In order to facilitate communication between common application classes,
	the protocol defines the subjects, verbs and attributes for common types
	of user activities. At the same time, new subjects, verbs and attributes
	can be defined and used by specialised applications.
      </para>

      <para>
	In addition to the metadata describing application activities, the
	protocol also specifies means through which application describe
	themselves to the user.
      </para>
    </section>

    <section xml:id="intro-xmpp">
      <title>XMPP/XPMN Backbone</title>

      <para>
	The Ytstenut communication protocols are built on the existing XMPP
	standard, using the XPMN protocol<citation><xref
	linkend="xpmn"/></citation> to construct the backbone of the application
	mesh.  The reasons for choosing XMPP as the basic transport protocol
	are:

	<itemizedlist>
	  <listitem>
	    <para>
	      Using an established messaging standard means that much of the
	      wheel needs not to be reinvented,
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      XMPP is supported on a broad range of hardware and software
	      platforms, thus aiding the speed with which the Ytstenut framework
	      can be rolled out,
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      XMPP is an open standard that can be used without difficulties
	      over licensing,
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      XMPP is extensible by design,
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      XMPP is capable of operating both in a server-based and
	      server-less manner, and supports both of these modes a in
	      transparent way,
	    </para>
	  </listitem>


	  <listitem>
	    <para>
	      XMPP is XML-based, so that implementation of extensions is
	      simplified by being able to use standard XML-processing tools,
	      such a parsers, etc.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	As far as possible, the Ytstenut framework aims to reuse existing XMPP
	capabilities and features; these are augmented by two extensions:

	<itemizedlist>
	  <listitem>
	    <para>
	      Protocols for encoding of Ytstenut metadata,
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      A server-less protocol similar to link-local XMPP<citation><xref
	      linkend="xep0174"/></citation> , but tailored for Ytstenut use.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	In addition, at number of points, the Ytstenut specification mandates
	the use of standard, but optional, XMPP features, particularly so, where
	this is desirable to improve security and privacy.
      </para>
    </section>

    <section xml:id="security">
      <title>Security and Privacy Considerations</title>

      <para>
	The flexible and extensible nature of the Ytstenut framework means that
	it is not possible to predict what kind of data may be transmitted via
	the protocol in its real-world deployment. Furthermore, the expectation
	of deployment on a variety of platforms, ranging from desktop computers
	to mobile phones, means that multiple implementations of the protocol
	will be in use. It is, therefore, important that security and privacy of
	user data is a key factor in the design of the protocol itself. More
	specifically:

	<itemizedlist>
	  <listitem>
	    <para>
	      The protocol must facilitate privacy of data in transit where that
	      is appropriate or required,
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Reliable identity verification mechanism must be available,
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      The protocol must provide structured access control to user's
	      local resources.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	With regards to the above, the following should be noted in particular:

	<itemizedlist>
	  <listitem>
	    <para>
	      XMPP on its on only provides client-to-server privacy. As such
	      XMPP exchanges that span multiple servers are susceptible to
	      server eavesdropping,
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Normal XMPP presence information is broadcast across all
	      subscribed contacts, or, in the case of link-local XMPP protocol,
	      even advertised entirely openly via m-DNS broadcasts; consequently
	      the the presence mechanism is not suitable for metadata exchanges,
	      including advertising extended status information (see <xref
	      linkend="messaging-status"/>).
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	The Ytstenut framework uses the XPMN protocol which addresses the
	security requirements above.
      </para>
    </section>
  </section>

  <?hard-pagebreak?>
  <section xml:id="local-ytstenut">
      <title>Link-local Ytstenut protocol</title>

      <para>
	The link-local Ytstenut protocol allows for automatic connection between
	Ytstenut clients running on the same LAN. It is derived from the
	local-xmpp protocol, but with some differences:

	<itemizedlist>
	  <listitem>
	    <para>
	      The link-local service is called 'ytstenut' rather than 'presence',
	      i.e., the PTRs have pattern 'JID._ytstenut._tcp._local.',
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      All implementations must fulfill the requirements of XPMN
	      <citation><xref linkend="xpmn"/></citation>.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>
  </section>

  <?hard-pagebreak?>
  <section xml:id="messaging">
    <title>Messaging Protocols</title>

    <section xml:id="messaging-device-info">
      <title>Descriptive Device Information</title>

      <annotation role="todo">
	<info>
	  <authorinitials>tf</authorinitials>
	  <orgname>Intel</orgname>
	</info>
	<para>
	  We need some way to advertise user-friendly device description; in
	  regular XMPP this usually provided by a vCard, but the vCard spec is
	  not suited for this too well.
	</para>
      </annotation>

      <para>
	Ytstenut device need to provide descriptive information about
	themselves that can be presented to the user. At the bare minimum, this
	information includes a suitable, localised, device name.
      </para>

      <section xml:id="messaging-device-info-avatars">
	<title>Support for Avatars</title>

	<para>
	  In addition to the device description advertised above, it is
	  recommended that all Ytstenut implementations support the XMPP User
	  Avatar specification<citation><xref linkend="xep0084"/></citation>.
	</para>
      </section>

    </section>

    <section xml:id="messaging-app-id">
      <title>Application/Service Identifier</title>

      <para>
	Each application/service is identified by a unique identifier. The
	identifier is constructed following the D-Bus naming
	convention<citation><xref linkend="dbus-spec"/></citation>, e.g.,
	<code>com.meego.BestestFriendApplication</code>. This identifier is used
	to identify message and status senders and recipients as described later
	in this document.
      </para>
    </section>

    <section xml:id="messaging-app-info">
      <title>Descriptive Application Information</title>

      <para>
	Ytstenut applications need to provide descriptive information about
	themselves that can be presented to the user. At the bare minimum, this
	information includes a suitable, localised, application name.
      </para>

      <para>
	The descriptive information is advertised together with the application
	capabilities, as described in <xref linkend="messaging-apps-caps"/>
      </para>
    </section>

    <section xml:id="messaging-app-caps">
      <title>Application/Service Capabilities</title>

      <para>
	Ytstenut applications/services advertise their Ytstenut capabilities via
	XMPP Entity Capabilities protocol<citation><xref
	linkend="xep0115"/></citation>, using
	<code>urn:ytstenut:capabilities</code> as the value of the
	<code>node</code> attribute of the <code>&lt;c/&gt;</code> element.
      </para>

      <para>
	When the device capabilities are queried, capabilities of each
	application/service are represented in the <code>&lt;iq/&gt;</code>
	reply using XMPP data form<citation><xref
	linkend="xep0004"/></citation>; the form format is best described by an
	example:
      </para>

      <annotation role="todo">
	<info>
	  <authorinitials>tf</authorinitials>
	  <orgname>Intel</orgname>
	</info>
	<para>
	  Need to formaly specify a localisation mechanism for the form fields.
	</para>
      </annotation>

      <programlisting><![CDATA[
<!-- a data form representing Banshee video player: -->
<x xmlns='jabber:x:data' type='result'>

  <field var='FORM_TYPE' type='hidden'>
    <value>urn:ytstenut:capabilities#org.gnome.Banshee</value>
  </field>

  <field var='type'>
    <value>application</value>
  </field>

  <field var='name'>
    <value>en_GB/Banshee Media Player</value>
    <value>fr/Banshee Lecteur de Musique</value>
  </field>

  <field var='capabilities'>
    <value>urn:ytstenut:capabilities:yts-caps-audio</value>
    <value>urn:ytstenut:data:jingle:rtp</value>
  </field>
</x>
]]></programlisting>

      <variablelist>
	<title>Data form fields:</title>

	<varlistentry>
	  <term><code>FORM_TYPE</code></term>
	  <listitem>
	    <para>
	      Links the form to the application; the value is constructed by
	      concatenating an <code>'urn:ytstenut:capabilies#'</code> prefix
	      with the application unique identifier (see <xref
	      linkend="messaging-app-id"/>),
	    </para>
	    <para>
	      Required.
	    </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><code>type</code></term>
	  <listitem>

      <annotation role="todo">
	<info>
	  <authorinitials>tf</authorinitials>
	  <orgname>Intel</orgname>
	</info>
	<para>
	  Review whether this distinction is really meaningfull, or whether
	  'control' should not be another kind of capability.
	</para>
      </annotation>

	    <para>
	      The application/service type; either <code>application</code> or
	      <code>controller</code>.
	    </para>

	    <para>
	      Required.
	    </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><code>name</code></term>
	  <listitem>
	    <para>
	     A localised application/service name.
	    </para>

	    <para>
	      Required.
	    </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><code>capabilities</code></term>

	  <listitem>
	    <para>
	      List of application/service capabilites; the values are
	      constructed by concatenating an
	      <code>'urn:ytstenut:capabilies:'</code> prefix and the canonical
	      name of the capability (for standard capabilities defined in <xref
	      linkend="messaging-metadata-caps"/>).
	    </para>
	    <para>
	      The capability list should further include any data transfer
	      protocols supported, using the <code>urn</code>s defined in <xref
	      linkend="messaging-data-transfer-urns"/> as additional values.
	    </para>

	    <para>
	      Required.
	    </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><code>vendor</code></term>
	  <listitem>
	    <para>
	      A localised vendor name.
	    </para>
	    <para>
	      Optional.
	    </para>
	  </listitem>
	</varlistentry>
      </variablelist>
    </section>

    <section xml:id="messaging-status">
      <title>Extended Status</title>

      <para>
	Extended status information is advertised using the XPMN eventing
	mechanism (which in turn relies on XMPP Personal Eventing
	Protocol<citation><xref linkend="xep0163"/></citation>). The status is
	identified with item node <code>urn:ytstenut:status</code> and the
	payload is held by an <code>&lt;ytstenut:status/&gt;</code> element and
	its attributes; applications with multiple capabilities must include an
	<code>&lt;ytstenut:status/&gt;</code> element for each capability.
      </para>

      <para>
	The following attributes, in addition to those defined in <xref
	linkend="messaging-metadata-attributes"/>, are used with the
	<code>&lt;ytstenut:status/&gt;</code> element:

	<variablelist>
	  <varlistentry>
	    <term><code>version</code></term>

	    <listitem>
	      <para>
		Ytstenut protocol version; required,
	      </para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><code>from-service</code></term>

	    <listitem>
	      <para>
		The ID of the application this status message describes;
		required (see <xref linkend="messaging-app-id"/>).
	      </para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><code>capability</code></term>

	    <listitem>
	      <para>
		The capability this status applies to; required. The value
		should be preferably one of those defined in <xref
		linkend="messaging-metadata-caps"/>,
	      </para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><code>activity</code></term>

	    <listitem>
	      <para>
		The activity this status represents; optional (if not present
		<code>yts-activity-idle</code> is implied). The value should be
		preferably one of those defined in <xref
		linkend="messaging-metadata-activity"/>
	      </para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><code>primary-capability</code></term>

	    <listitem>
	      <para>
		Boolean indicating whether capability this status applies to is
		the primary capability of the application; optional (if absent
		<code>false</code> is implied).
	      </para>
	    </listitem>
	  </varlistentry>

	</variablelist>
      </para>

      <para>
	While the <code>&lt;ytstenut:status/&gt;</code> element can be extended
	with custom attributes, no frequently changing information
	(such as current playback position) is permitted as part of status to
	avoid flooding of the network.
      </para>

      <para>
	Human readable description is provided using one or more
	<code>&lt;ytstenut:description/&gt;</code> elements inside the
	<code>&lt;ytstenut:status/&gt;</code> element; each
	<code>&lt;ytstenut:description/&gt;</code> element must have an
	<code>xml:lang</code> attribute, and multiple
	<code>&lt;ytstenut:description/&gt;</code> elements must have a different
	<code>xml:lang</code> attribute each.
      </para>

	<example xml:id="messaging-status-example">
	  <title>Status XML example</title>

	  <programlisting><![CDATA[
<ytstenut:status version='1.0'
                from-service='com.meego.BestestFriendApplication'
                capability='yts-caps-video'
                activity='yts-activity-play'
                uri='some random youtube url'
                volume='0.75'>
  <ytstenut:description xml:lang='en-GB'>
    Playing a video about colour-based optical illusions.
  </ytstenut:description>
</ytstenut:status>]]>
	  </programlisting>
	</example>
    </section>

    <section xml:id="messaging-commands">
      <title>Instruction Messages</title>

      <para>
	Instruction messages are used to send Ytstenut commands and information
	queries; as per XPMN this is achieved by exchanging
	<code>&lt;iq/&gt;</code>stanzas with the Ytstenut metadata payload.
      </para>

      <section xml:id="messaging-commands-message">
	<title>Message payload: <code>&lt;ytstenut:message/&gt;</code></title>

	<para>
	  The <code>&lt;ytstenut:message/&gt;</code> element is used to
	  encapsulate the payload of standardised Ytstenut messages.
	</para>

	<para>
	  Required attributes:

	  <variablelist>
	    <varlistentry>
	      <term>
		<code>version</code>
	      </term>
	      <listitem>
		<para>
		  The Ytstenut protocol version,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>from-service</code></term>

	      <listitem>
		<para>
		  The ID of the application that sent this message;
		  required (see <xref linkend="messaging-app-id"/>).
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>to-service</code></term>

	      <listitem>
		<para>
		  The ID of the application that this message is for;
		  required (see <xref linkend="messaging-app-id"/>).
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>type</code>
	      </term>
	      <listitem>
		<para>
		  Message type. Standaridsed types have the prefix
		  <code>ytstenut/</code> and are defined in the following
		  section. Custom command types are permitted, and must use a
		  suitable namespace prefix (other than <code>ytstenut/</code>).
		</para>
	      </listitem>
	    </varlistentry>
	  </variablelist>
	</para>

	<para>
	  Depending on the message purpose, additional attributes are used to
	  define the message payload; there are no standard child elements
	  defined by this specification, but custom child elements are allowed.
	</para>

      </section>

      <section xml:id="messaging-commands-types">
	<title>Standardised Message Types</title>

	<section xml:id="messaging-commands-command">
	  <title><code>ytstenut/command</code></title>

	  <para>
	    A command sent from application <code>A</code> to application
	    <code>B</code> to executed directly by application <code>B</code>.
	  </para>
	  <para>
	    Required <code>&lt;ytstenut:message/&gt;</code> attributes:

	    <variablelist>
	      <varlistentry>
		<term>
		  <code>capability</code>
		</term>
		<listitem>
		  <para>
		    Capability on which the command is to operate, preferably
		    using one of the values defined in <xref
		    linkend="messaging-metadata-caps"/>,
		  </para>
		</listitem>
	      </varlistentry>

	      <varlistentry>
		<term>
		  <code>activity</code>
		</term>
		<listitem>
		  <para>
		    Activity to carry out, preferably using one of the values
		    defined in <xref linkend="messaging-metadata-activity"/>,
		  </para>
		</listitem>
	      </varlistentry>

	      <varlistentry>
		<term>
		  <code>time</code>
		</term>
		<listitem>
		  <para>
		    Time of command dispatch with at least millisecond
		    precision, in standard XMPP format<citation><xref
		    linkend="xep0082"/></citation>.
		  </para>
		</listitem>
	      </varlistentry>
	    </variablelist>
	  </para>

	  <para>
	    Additional attributes, preferably using those defined in <xref
	    linkend="messaging-metadata-attributes"/>, are used to further
	    qualify the capability and activity specified.
	  </para>

    <example xml:id="messaging-commands-example"> <title>Command example</title>

      <para>
	The following XML snippet tells some other application to start
	playing given video starting 3/4 into the video duration:
      </para>

      <programlisting><![CDATA[

<iq type='set'
    id='command1'
    to='myself@blackbox.local/magic-video-player'
    >
    <ytstenut:message version='1.0'
                      type='ytstenut/command'
                      time='1970-01-01T00:00:00.000Z'
                      from-service='com.meego.BestestFriendApplication'
                      to-service='com.meego.BestestFriendApplication'
                      capability='yts-caps-video'
                      activity='yts-activity-play'
                      uri='some random youtube url'
                      progress='0.75'>
        [Optional command data; binary data base64 encoded]
    </ytstenut:message>
</iq>

 ...

<iq type='result'
    id='command1'
    to='myself@bluebox.local/the-other-player'
    from='myself@blackbox.local/magic-video-player'
    xmlns='urn:ytstenut:messages'/>]]>
      </programlisting>
    </example>

	  <section xml:id="messaging-commands-command-error">
	    <title>Error handling</title>
	    <para>
	      When the resource to which the Ytstenut command pertains is
	      unavailable, the command recipient should return an error that
	      best describes reason why:

	      <variablelist>
		<varlistentry>
		  <term><code>&lt;forbidden/&gt;</code></term>
		  <listitem>
		    <para>
		      The recipient does not have sufficient privileges to
		      carry out the command.
		    </para>
		  </listitem>
		</varlistentry>

		<varlistentry>
		  <term><code>&lt;item-not-found/&gt;</code></term>
		  <listitem>
		    <para>
		      The resource could not be located.
		    </para>
		  </listitem>
		</varlistentry>
	      </variablelist>
	    </para>
	    <para>
	      The <code>type</code> attribute of the
	      <code>&lt;error/&gt;</code> stanza should be set appropriately:
	      the <code>modify</code> value should be used if the recipient is
	      able to explore other sources for the same resource; the value
	      <code>cancel</code> is used to indicate that no further attempts
	      to execute this command should be made.
	    </para>

	    <para>
	      When handling errors of type <code>modify</code>, the sender must
	      explore each possible source no more than once. When all known
	      sources are exhausted, the initiating application should notify
	      user that the command could not be executed.
	    </para>
	  </section>
	</section>

	<section xml:id="messaging-commands-transfer">
	  <title><code>ytstenut/transfer</code></title>

	  <para>
	    A request by application <code>A</code> to application
	    <code>B</code> to transfer <code>B</code>'s activity to application
	    <code>C</code>.
	  </para>

	  <para>
	    Required <code>&lt;ytstenut:message/&gt;</code> attributes:

	    <variablelist>
	      <varlistentry>
		<term>
		  <code>capability</code>
		</term>
		<listitem>
		  <para>
		    Capability that is subject of the transfer,
		  </para>
		</listitem>
	      </varlistentry>

	      <varlistentry>
		<term>
		  <code>jid</code>
		</term>
		<listitem>
		  <para>
		    JID of the application to transfer to.
		  </para>
		</listitem>
	      </varlistentry>
	    </variablelist>
	  </para>

	  <para>
	    Additional attributes, preferably using those defined in <xref
	    linkend="messaging-metadata-attributes"/>, may be used to further
	    qualify the capability specified.
	  </para>

	</section>

	<section xml:id="messaging-commands-find">
	  <title><code>ytstenut/find</code></title>

	  <annotation role='comment'>
	    <info>
	      <authorinitials>tf</authorinitials>
	      <orgname>Intel</orgname>
	    </info>
	    <para>
	      Rationale: because of the need to
	      facilitate e2e encryption, commands cannot be proxied through
	      control applications; the <code>find</code> request allows
	      clients to initiate a transfer to an application that might
	      not yet be running on the target device.
	    </para>

	    <para>
	      Not allowing proxying of commands via intermediate applications
	      also significantly simplifies issues related to access control.
	    </para>
	  </annotation>

	  <para>
	    A request by an application <code>A</code> to a control application
	    <code>C</code> to identify a suitable application <code>B</code> to
	    dispatch a (subsequent) command to:

	    <itemizedlist>
	      <listitem>
		<para>
		  The criteria for the search is given by the supplied
		  attributes (e.g., application capability would be specified
		  using the <code>capability</code> attribute),
		</para>
	      </listitem>

	      <listitem>
		<para>
		  The search is limited to the service context the control
		  application is part of, or, in the case of the home cloud, the
		  device the control application is running on,
		</para>
	      </listitem>

	      <listitem>
		<para>
		  The control application returns the result of the search using
		  the <code>jid</code> attribute of the
		  <code>&lt;ytstenut:message/&gt;</code> payload.
		</para>
	      </listitem>
	    </itemizedlist>
	  </para>

	  <section xml:id="messaging-commands-find-error">
	    <title>Error handling</title>

	    <para>
	      If no suitable running application matching the specified criteria
	      can be identified but a suitable application is available on the
	      system, the control application must return immediately with
	      status <code>executing</code>, then attempt to start such suitable
	      application.
	    </para>

	    <para>
	      If a suitable application does not exist on the system, the
	      control application must return immediately an error condition
	      <code>&lt;item-not-found/&gt;</code>.
	    </para>

	    <para>
	      When the spawned client application successfully starts up, the
	      control application returns the result of the search using the
	      <code>jid</code> attribute of the
	      <code>&lt;ytstenut:message/&gt;</code> payload. If the application
	      fails to start, the control application must dispatch response
	      with status <code>completed</code> and an error; the error
	      condition should indicate why the application failed to start, if
	      that is known.
	    </para>
	  </section>
	</section>
      </section>
    </section>

    <section xml:id="messaging-metadata">
      <title>Common metadata classes</title>

      <para>
	The canonical definition is given in <xref linkend="appendix-schemas"/>;
	the following information is extracted from the XML schemas for
	convenience.
      </para>


      <section xml:id="messaging-metadata-caps">
	<title>Common capability classes</title>

	<para>
	  <variablelist>
	    <varlistentry>
	      <term>
		<code>yts-caps-control</code>
	      </term>

	      <listitem>
		<para>
		  control application,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-caps-audio</code>
	      </term>

	      <listitem>
		<para>
		  audio playback capabilities,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-caps-video</code>
	      </term>

	      <listitem>
		<para>
		  video playback capabilities,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-caps-image</code>
	      </term>

	      <listitem>
		<para>
		  image display capabilities,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-caps-html</code>
	      </term>

	      <listitem>
		<para>
		  html rendering capabilities,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-caps-antivirus</code>
	      </term>

	      <listitem>
		<para>
		  anti-virus capabilities,
		</para>
	      </listitem>
	    </varlistentry>

	  </variablelist>
	</para>

	<annotation role='comment'>
	    <info>
	      <authorinitials>tf</authorinitials>
	      <orgname>Intel</orgname>
	    </info>
	    <para>
	      More standard definitions should be added here; open to
	      suggestions.
	    </para>
	  </annotation>

	<para>
	  Custom capabilities can be defined, providing these are suitably
	  name-spaced with a custom prefix; custom capabilities must not use
	  'yts-' prefix.
	</para>
      </section>

      <section xml:id="messaging-metadata-activity">
	<title>Common activity classes</title>

	<para>
	  Absence of the 'activity' attribute, or its empty value, imply idle
	  state.

	  <variablelist>
	    <varlistentry>
	      <term>
		<code>yts-activity-playback</code>
	      </term>

	      <listitem>
		<para>
		  playback,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-activity-pause</code>
	      </term>
	      <listitem>
		<para>
		  paused state,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-activity-ffw</code>
	      </term>
	      <listitem>
		<para>
		  fast forward,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-activity-rwd</code>
	      </term>
	      <listitem>
		<para>
		  rewind,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-activity-scan</code>
	      </term>
	      <listitem>
		<para>
		  scan,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>
		<code>yts-activity-volume</code>
	      </term>
	      <listitem>
		<para>
		  volume adjustment.
		</para>
	      </listitem>
	    </varlistentry>
	  </variablelist>
	</para>

	<annotation role='comment'>
	  <info>
	    <authorinitials>tf</authorinitials>
	    <orgname>Intel</orgname>
	  </info>
	  <para>
	  More standard definitions should be added here, open to suggestions.
	  </para>
	</annotation>

	<para>
	  Custom activities can be defined, providing these are suitably
	  name-spaced with a custom prefix; custom activities must not use 'yts-'
	  prefix.
	</para>
      </section>

      <section xml:id="messaging-metadata-attributes">
	<title>Common attributes</title>

	<para>
	  <variablelist>
	    <varlistentry>
	      <term><code>protocol</code></term>

	      <listitem>
		<para>
		  <code>urn</code> identifying a suitable protocol through which
		  the resource on which to operate can be obtained (see <xref
		  linkend="messaging-data-transfer-urns"/>). Multiple protocols
		  can be listed as a space separated list, in descending order
		  of preference.
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>uri</code></term>

	      <listitem>
		<para>
		  <code>uri</code> a of a resource associated with activity.
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>uid</code></term>

	      <listitem>
		<para>
		  Universal id identifying resource associated with activity,

		<annotation role='comment'>
		  <info>
		    <authorinitials>tf</authorinitials>
		    <orgname>Intel</orgname>
		  </info>
		  <para>
		    The idea is being able to use something like, for example,
		    musicbrainz id to identify the resource, though in practice
		    this might be hard to extend beyond audio
		  </para>
		</annotation>
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>volume</code></term>

	      <listitem>
		<para>
		  volume level (floating point number from &lt;0,1&gt;),
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>progress</code></term>

	    <listitem>
	      <para>
		activity progress (floating point number from
		&lt;0,1&gt; this is the preferred way of passing information
		such as stream position,
	      </para>
	    </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>position</code></term>

	      <listitem>
		<para>
		  activity position (floating point number); NB: applications
		  should use the <code>progress</code> attribute whenever
		  possible instead of 'position',
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>description</code></term>

	      <listitem>
		<para>
		  description: human readable description, suitable for
		  presentation to user,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>jid</code></term>

	      <listitem>
		<para>
		  XMPP id,
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>speed</code></term>

	      <listitem>
		<para>
		  speed of activity (floating point number; 1.0 indicates
		  normal speed).
		</para>
	      </listitem>
	    </varlistentry>
	  </variablelist>
	</para>

	<para>
	  Custom attributes can be defined, providing these are suitably
	  name-spaced with a custom prefix; custom attributes must not use 'yts-'
	  prefix.
	</para>
      </section>

    </section>
    <section xml:id="messaging-data-transfer">
      <title>Data Transfer Protocols</title>

      <para>
	This section defines standard data transfer protocols to be used by
	Ytstenut clients; this list does not restrict clients to these protocols
	alone, but sets out preferred protocols.
      </para>

      <section xml:id="messaging-data-transfer-files">
	<title>File Transfers</title>

	<para>
	  <itemizedlist>
	    <listitem>
	      <para>
		The preferred file transfer protocol is SI File
		Transfer<citation><xref linkend="xep0096"/></citation>; this
		protocol must be supported by all compliant Ytstenut clients for
		which a <code>file</code> constitutes a meaningful data unit,
	      </para>
	    </listitem>

	    <listitem>
	      <para>
		It is recommended that clients also implement Jingle
		File Transfer<citation><xref linkend="xep0234"/></citation>;
		this protocol is currently in experimental stage, but once it is
		reaches the draft stage, it will be adopted as the default file
		transfer protocol for Ytstenut clients.
	      </para>
	    </listitem>
	  </itemizedlist>
	</para>
      </section>

      <section xml:id="messaging-data-transfer-streaming">
	<title>Streaming</title>

	<para>
	  The preferred streaming protocol is XMPP Jingle RTP<citation><xref
	  linkend="xep0167"/></citation>; applications that support media
	  streaming should implement this protocol.
	</para>
      </section>

      <section xml:id="messaging-data-transfer-urns">
	<title>URNs for common resource fetching protocols</title>

	<para>
	  This section codifies <code>urn</code>s to be used with the
	  <code>uri</code> attribute of Ytstenut commands to indicate how to
	  reach the resource, and when advertising application capabilities (see
	  <xref linkend="messaging-app-caps"/>). Each <code>urn</code> is formed
	  by combining a '<code>urn:ytstenut:data:</code>' prefix with one of the
	  protocol ids defined below:
	</para>
	<para>
	  <variablelist>
	    <varlistentry>
	      <term><code>si-file</code></term>

	      <listitem>
		<para>
		  Resource can be obtained from initiating application using SI
		  File Transfer<citation><xref linkend="xep0096"/></citation>,
		  see <xref linkend="messaging-data-transfer-files"/>.
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>jingle:ft</code></term>

	      <listitem>
		<para>
		  Resource can be obtained from initiating application using
		  XMPP Jingle File Transfer<citation><xref
		  linkend="xep0234"/></citation>, see <xref
		  linkend="messaging-data-transfer-files"/>.
		</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><code>jingle:rtp</code></term>

	      <listitem>
		<para>
		  Resource can be obtained from initiating application using
		  XMPP Jingle RTP<citation><xref linkend="xep0167"/></citation>,
		  see <xref linkend="messaging-data-transfer-streaming"/>
		</para>
	      </listitem>
	    </varlistentry>
	  </variablelist>
	</para>
      </section>
    </section>
  </section>

  <?hard-pagebreak?>
  <appendix xml:id="appendix-schemas">
    <title>Ytstenut XML Schemas</title>

    <section xml:id="appendix-schemas-ytstenut-status">
      <title>Schema for <code>urn:ytstenut:status</code></title>
      <programlisting><!-- The xi:include line must be aligned directly at the
			   end of this comment, as any padding will end up in
			   the final document !!!
		      --><xi:include
	     parse="text"
	     href="./ytstenut-protocol-status.xsd" /></programlisting>
    </section>

    <section xml:id="appendix-schemas-ytstenut-messages">
      <title>Schema for <code>urn:ytstenut:messages</code></title>
      <programlisting><!-- The xi:include line must be aligned directly at the
			   end of this comment, as any padding will end up in
			   the final document !!!
		      --><xi:include
	     parse="text"
	     href="./ytstenut-protocol-messages.xsd" /></programlisting>
    </section>
  </appendix>

  <?hard-pagebreak?>
  <bibliography>
    <title>External Resources</title>
    <bibliodiv>
    <title></title>

    <biblioentry xml:id="rfc3920">
      <title>RFC 3920</title>
      <subtitle>Extensible Messaging and Presence Protocol (XMPP):
      Core</subtitle>
      <publishername>The Internet Engineering Task Force</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://tools.ietf.org/html/rfc3920"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="rfc3921">
      <title>RFC 3921</title>
      <subtitle>Extensible Messaging and Presence Protocol (XMPP): Instant
      Messaging and Presence</subtitle>
      <publishername>The Internet Engineering Task Force</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://tools.ietf.org/html/rfc3921"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="rfc2222">
      <title>RFC 2222</title>
      <subtitle>Simple Authentication and Security Layer (SASL)</subtitle>
      <publishername>The Internet Engineering Task Force</publishername>
      <bibliosource>
	<link xlink:href="http://tools.ietf.org/html/rfc2222"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="rfc3923">
      <title>RFC 3923</title>
      <subtitle>End-to-End Signing and Object Encryption for the Extensible
      Messaging and Presence Protocol (XMPP)</subtitle>
      <publishername>The Internet Engineering Task Force</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://tools.ietf.org/html/rfc3923"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xpmn">
      <author>
	<personname>
	  <firstname>Dirk</firstname> <surname>Meyer</surname>
	</personname>
      </author>
      <title>Extended Personal Media Networks (XPMN)</title>
      <publishername>University of Bremen</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://elib.suub.uni-bremen.de/diss/docs/00011878.pdf"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0004">
      <title>XEP-0004</title>
      <subtitle>Data Forms</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0004.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0030">
      <title>XEP-0030</title>
      <subtitle>Service Discovery</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0030.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0050">
      <title>XEP-0050</title>
      <subtitle>Ad-Hoc Commands</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0050.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0060">
      <title>XEP-0060</title>
      <subtitle>Publish-Subscribe</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0060.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0082">
      <title>XEP-0082</title>
      <publishername>XMPP Standards Foundation</publishername>
      <subtitle>XMPP Date and Time Profiles</subtitle>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0082.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0084">
      <title>XEP-0084</title>
      <subtitle>User Avatar</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0084.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0096">
      <title>XEP-0096</title>
      <subtitle>SI File Transfer</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0096.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0115">
      <title>XEP-0115</title>
      <subtitle>Entity Capabilities</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0115.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0163">
      <title>XEP-0163</title>
      <subtitle>Personal Eventing Protocol</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0163.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0166">
      <title>XEP-0166</title>
      <subtitle>Jingle</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0166.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0167">
      <title>XEP-0167</title>
      <subtitle>Jingle RTP Sessions</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0167.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0174">
      <title>XEP-0174</title>
      <subtitle>Serverless Messaging</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0174.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="xep0234">
<!--
      <author>
	<personname>
	  <firstname>Peter</firstname>
	  <surname>Saint-Andre</surname>
	</personname>
      </author>
-->
      <title>XEP-0234</title>
      <subtitle>Jingle File Transfer</subtitle>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/xep-0234.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="jng-xtls">
      <title>Jingle XTLS</title>
      <publishername>XMPP Standards Foundation</publishername>
      <bibliosource class="uri">
	<link xlink:href="http://xmpp.org/extensions/inbox/jingle-xtls.html"/>
      </bibliosource>
    </biblioentry>

    <biblioentry xml:id="dbus-spec">
      <title>D-Bus Specification</title>
      <bibliosource class="uri">
	<link xlink:href="http://dbus.freedesktop.org/doc/dbus-specification.html"/>
      </bibliosource>
    </biblioentry>

    </bibliodiv>
  </bibliography>
</article>