%ents; ]>
In-Band Bytestreams (IBB) This document defines an XMPP protocol extension for bytestreaming data in band between any two entities over Jabber/XMPP. &LEGALNOTICE; 0047 Draft Standards Track Standards JIG XMPP Core XEP-0079 http://www.xmpp.org/schemas/ibb.xsd ibb &infiniti; 1.0 2003-12-10 psa Per a vote of the Jabber Council, advanced status to Draft. 0.8 2003-12-04 jk Add 'block-size' attribute and usage guidelines 0.7 2003-05-23 jk Use IQ for shutdown, remove XEP-0022 dependency, loop the counter 0.6 2003-05-14 jk Use message for delivery 0.5 2003-04-06 jk Changed newseq to prevseq, added acks, changed seq size to 32-bit 0.4 2003-03-22 jk Changed protocol, added sequence id 0.3 2002-12-10 jk Removed the 'comment' block, changed namespace 0.2 2002-10-10 jk Revised the text 0.1 2002-09-29 jk Initial version.

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.

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.

 ]]>

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.

]]>

This is a success response from juliet@capulet.com/balcony, saying that the bytestream is active.

]]>

This is an error response from juliet@capulet.com/balcony saying that an In-Band Bytestreams is not possible.

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.

qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA ]]>

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.

It is possible that the message may fail to be delivered:

... ]]>

Upon delivery failure, the sender MUST consider the bytestream to be closed and invalid.

To close the bytestream, send the following:

]]> ]]>

This is a success response from juliet@capulet.com/balcony, saying that the bytestream is now closed.

]]>

Upon error, the bytestream MUST be considered closed and invalid.

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.

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.

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.

This document requires no interaction with &IANA;.

The ®ISTRAR; shall register the 'http://jabber.org/protocol/ibb' namespace as a result of this document.

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