moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

1.1pre1 from Justin Karneges

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@192 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-11-21 00:01:51 +00:00
parent f13f39d1eb
commit 02d17475e2
1 changed files with 40 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
xep-0047.xml
View File

@ -24,6 +24,12 @@
</schemaloc>
<shortname>ibb</shortname>
&infiniti;
<revision>
<version>1.1pre1</version>
<date>in progress, last updated 2006-11-03</date>
<initials>jk</initials>
<remark>Allow IQ for delivery.</remark>
</revision>
<revision>
<version>1.0</version>
<date>2003-12-10</date>
@ -129,8 +135,8 @@
</section2>
<section2 topic='Sending data'>
<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>
<example caption='Sending data'><![CDATA[
<p>Data is sent using either &lt;message&gt; or &lt;iq&gt; stanzas. Either participant in the bytestream may send such packets. The data to be sent, prior to any encoding or wrapping in the stanza, must be no larger than the 'block-size' determined in the stream negotiation. All stanzas 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. When using &lt;message&gt; stanzas, &xep0079; SHOULD be used to ensure that the data packet is not spooled or sent to the wrong resource.</p>
<example caption='Sending data using message'><![CDATA[
<message from='romeo@montague.net/orchard' to='juliet@capulet.com/balcony' id='msg1'>
<data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
@ -146,11 +152,30 @@
</message>
]]></example>
<p>The data to send is included as XML character data of the &lt;data/&gt; 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>
<example caption='Sending data using iq'><![CDATA[
<iq from='romeo@montague.net/orchard' to='juliet@capulet.com/balcony' type='set' id='ibb1'>
<data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu
IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P
AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH
kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
</data>
</iq>
]]></example>
<p>It is possible that the message may fail to be delivered:</p>
<p>The data to send is included as XML character data of the &lt;data/&gt; element after being encoded as Base64 as specified in Section 3 of &rfc3548;. The 'seq' attribute is a 16-bit unsigned 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>
<example caption='Failed delivery'><![CDATA[
<p>Note that in the case of iq stanzas, the recipient must reply with an iq of type 'result'.</p>
<example caption='Acknowledging data using iq'><![CDATA[
<iq from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard' type='result' id='ibb1'/>
]]></example>
<p>The sender need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize possible rate-limiting penalties.</p>
<p>It is possible that the stanza may fail to be delivered:</p>
<example caption='Failed delivery with message'><![CDATA[
<message from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard' id='msg1' type='error'>
...
<error code='504' type='cancel'>
@ -159,6 +184,15 @@
</message>
]]></example>
<example caption='Failed delivery with iq'><![CDATA[
<iq from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard' id='ibb1' type='error'>
...
<error code='504' type='cancel'>
<remote-server-timeout xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>Upon delivery failure, the sender MUST consider the bytestream to be closed and invalid.</p>
</section2>
@ -209,6 +243,7 @@
<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>&lt;message&gt; delivery SHOULD be used when &xep0079; or other stanza flow-control facilities are available. However, if they are not available, then &lt;iq&gt; SHOULD be used.</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>