<remark>More restrictive on usage of "action" attributes; Reduced session information returned in most use-cases; Added action for retrieving session information; Added action for service ("proxy") invites</remark>
</revision>
<revision>
<version>0.3</version>
<date>2002-10-20</date>
<initials>lw</initials>
<remark>Complete overhaul (redesign to allow for peer-to-peer operation; reduced element-set; removed "session types"; reorganized into use-cases)</remark>
</revision>
<revision>
<version>0.2</version>
<date>2002-08-20</date>
<initials>lw</initials>
<remark>Added "detailed" description of OOB headers</remark>
</revision>
<revision>
<version>0.1</version>
<date>2002-08-14</date>
<initials>lw</initials>
<remark>Initial Release</remark>
</revision>
</header>
<section1topic='Overview'>
<section2topic='Introduction'>
<p>Distributing data out-of-band (OOB) to one or more end-points is a requirement for many Jabber clients. The Jabber OOB Broadcast Service (JOBS) is a mechanism to allow end-points to open uni-directional data streams between each other, on top of which any number of applications can be built <note>Possible applications include file transfer, audio/video streaming, and some gaming implementations.</note>.</p>
<p>As the name implies, JOBS is designed to enable multicast, uni-directional OOB connections. These connections are usually between a "sender" client, a JOBS "service", and one or more "receiver" clients. Each such set of connections is collectively called a session. JOBS is designed to allow a single service to handle multiple sessions over a single host/port combination.</p>
<p>To address a large number of typical uses efficiently, JOBS can multicast the data from a sender to multiple receivers. In order to keep the protcol as simple as possible, it only allows data to flow in one direction.</p>
<p>JOBS utilizes a "two-band" authentication mechanism. This allows the end-points to know practically nothing about each other, yet still be assured that the OOB connection is really to/from the Jabber entity its intended to be. The authentication system is then backed-up with explicit authorization requests.</p>
<p>For the OOB portion, clients connect to the host/address and port of the JOBS service for a given session. Once connected, a client-initiated handshake process occurs, and (if successful), then data is routed from the sender's connection to each receiver's connection. The only point at which any error information may be conveyed over the OOB connection is during the handshake process.</p>
<p>To determine support for JOBS via jabber:iq:browse, look for an item with a nested <ns/> with a value of "http://jabber.org/protocol/jobs":</p>
<p>The JOBS protocol supports various scenarios to create sessions. Most of these scenarios allow an entity to determine the possible parameters to create a session with. To actually create a session, the (would-be) sender sends an "iq-set" with a <session action="create"/>. This returns the details of the newly created session, including the ID and OOB host/port.</p>
<p>This creates a session between sender@domain/resource and any one receiver. At this point, the JOBS service is ready to accept connections for this session. The <session/> element describes the details for the session. The value returned in the "id" attribute is the JOBS session ID <note>The exact value of the ID is left to JOBS implementations.</note>.</p>
</section3>
<section3topic='With Parameters'>
<p>When creating a session, parameters to <session/> can be supplied, explicitly requesting that certain parameters be met (such as buffer size, time to expire, and receiver limit). Since these parameters have lower- and upper-bounds specific to the JOBS service, a sender may need to determine these limits.</p>
<p>To create a session with specific parameters, the sender sends an "iq-set" as in the "simple" use-case, but then specifying the parameter values desired:</p>
<examplecaption='Creation request, with parameters'><