1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
This commit is contained in:
stpeter 2011-02-23 15:42:32 -07:00
parent b40b8b760e
commit f1a7164227

View File

@ -26,10 +26,10 @@
&infiniti;
&stpeter;
<revision>
<version>1.3rc2</version>
<date>in progress, last updated 2010-03-10</date>
<version>1.3rc3</version>
<date>in progress, last updated 2011-02-23</date>
<initials>psa</initials>
<remark><p>Clarified error handling and block construction.</p></remark>
<remark><p>Clarified error handling, block construction, and bytestream closing.</p></remark>
</revision>
<revision>
<version>1.2</version>
@ -100,7 +100,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This document describes In-Band Bytestreams (IBB), an XMPP protocol extension that enables two entities to establish a virtual bytestream over which they can exchange Base64-encoded chunks of data over XMPP itself. Because IBB provides a generic bytestream, its usage is open-ended. To date it has been used as a fallback method for sending files when out-of-band methods such as &xep0065; are not available. However, IBB could also be useful for any kind of relatively low-bandwidth activity, such as games, shell sessions, or encrypted text.</p>
<p>This document describes In-Band Bytestreams (IBB), an XMPP protocol extension that enables two entities to establish a virtual bytestream over which they can exchange Base64-encoded chunks of data over XMPP itself. Because IBB provides a generic bytestream, its usage is open-ended. To date it has been used as a fallback method for sending files (see &xep0096; and &xep0234;) when out-of-band methods such as &xep0065; are not available. However, IBB could also be useful for any kind of relatively low-bandwidth activity, such as games, shell sessions, or encrypted text.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
@ -225,7 +225,7 @@
<close xmlns='http://jabber.org/protocol/ibb' sid='i781hf64'/>
</iq>
]]></example>
<p>The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result.</p>
<p>The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result (however, the receiving party might wait until it has had a chance to send any remaining data in the other direction, if the bytestream is bidirectional; in this case, the party that sent the original &lt;close/&gt; element SHOULD wait to receive the IQ response from the receiving party before considering the bytestream to be closed).</p>
<example caption='Success response'><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='us71g45j'