<remark>Removed the 'comment' block, changed namespace</remark>
</revision>
<revision>
<version>0.2</version>
<date>2002-10-10</date>
<initials>jk</initials>
<remark>Revised the text</remark>
</revision>
<revision>
<version>0.1</version>
<date>2002-09-29</date>
<initials>jk</initials>
<remark>Initial version.</remark>
</revision>
</header>
<section1topic='Introduction'>
<p>This document describes In-Band Bytestreams (or IBB), a reliable bytestream protocol between two Jabber entities over a Jabber XML stream. The basic idea is that binary data is encoded as Base64 and transferred over the Jabber network.</p>
<p>IBB is a generic bytestream, and so its usage is left open-ended. It is likely to be useful for sending small payloads, such as files that would otherwise be too cumbersome to send as an instant message (such as a text file) or impossible to send (such as a small binary image file). It could also be useful for any kind of low-bandwidth activity, such as a chess game or a shell session. And, while it is mostly intended as a fallback in situations where a &xep0065; is unavailable, IBB could be more desirable for many of the simple bytestream use-cases that do not have high bandwidth requirements.</p>
<examplecaption='Initiation of Interaction'><![CDATA[
<iqtype='set'
from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
id='inband_1'>
<opensid='mySID'
block-size='4096'
xmlns='http://jabber.org/protocol/ibb'/>
</iq>
]]></example>
<p>This asks Juliet if she would like to form an In-Band Bytestreams connection, using the session ID 'mySID' (generated by the initiator here) to uniquely reference the bytestream. The 'block-size' attribute specifies the maximum amount of data (in bytes) that an IBB packet may contain.</p>
<examplecaption='Success Response'><![CDATA[
<iqtype='result'
from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='inband_1'/>
]]></example>
<p>This is a success response from juliet@capulet.com/balcony, saying that the bytestream is active.</p>
<p>Data is sent using message stanzas. Either participant in the bytestream may send such packets. The data to be sent, prior to any encoding or wrapping in the message stanza, must be no larger than the 'block-size' determined in the stream negotiation. All packets are to be addressed to the FULL JID of the bytestream peer. In order to keep track of stanzas sent and any errors received, the sender SHOULD include the 'id' attribute on stanzas sent to the recipient. Note that &xep0079; SHOULD be used to ensure that the data packet is not spooled or sent to the wrong resource.</p>
<p>The data to send is included as XML character data of the <data/> element after being encoded as Base64 as specified in Section 3 of &rfc3548;. The 'seq' attribute is a 16-bit integer counter starting at 0, and MUST be incremented for each packet sent. Thus, the next packet sent should have a 'seq' of 1, the one after that with a 'seq' of 2, and so on. The counter loops at maximum, so after value 65535, 'seq' MUST start again at 0.</p>
<p>It is possible that the message may fail to be delivered:</p>
<p>Upon error, the bytestream MUST be considered closed and invalid.</p>
</section2>
<section2topic='Receiving packets'>
<p>Data packets MUST be processed in the order they are received. If an out-of-sequence packet is received for a particular bytestream (determined by checking the 'seq' attribute), then this indicates that a packet has been lost. The recipient MUST NOT process the data of such an out-of-sequence packet, nor any that follow it within the same bytestream, and at this point MUST consider the bytestream closed and invalid.</p>
</section2>
</section1>
<section1topic='Usage Guidelines'>
<ul>
<li>Generally, IBB should be used as a last resort. <strong>SOCKS5 Bytestreams</strong> will almost always be preferable.</li>
<li>A server MAY rate limit a connection, depending on the size and frequency of data packets.</li>
<li>A server MAY disconnect a connection that sends overly large packets as defined by server policy.</li>
<li>It is RECOMMENDED to use a 'block-size' of 4096.</li>
<li>For proper tracking of message delivery errors, the use of the stanza 'id' attribute is RECOMMENDED.</li>
</ul>
</section1>
<section1topic='Security Considerations'>
<p>In-Band Bytestreams is as secure as the underlying Jabber transport. The bytestream application could have its own security layer, but this is outside of the scope of IBB.</p>
<p>An entity MUST verify any Base64 data received. An implementation MUST reject (not ignore) any characters that are not explicitly allowed by the Base64 alphabet; this helps to guard against creation of a covert channel that could be used to "leak" information. An implementation MUST NOT break on invalid input and MUST reject any sequence of Base64 characters containing the pad ('=') character if that character is included as something other than the last character of the data (e.g. "=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow attacks and other attacks on the implementation. Base encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality. Base64 encoding MUST follow the definition in Section 3 of RFC 3548.</p>
