/usr/share/doc/telepathy-gabble/tubes.html is in telepathy-gabble 0.18.3-1+b1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 | <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-loose.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>XEP-proto-tubes: Tubes over XMPP</title><link rel="stylesheet" type="text/css" href="../xmpp.css" /><link href="../prettify.css" type="text/css" rel="stylesheet" /><link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" /><script type="text/javascript" src="../prettify.js"></script><meta name="DC.Title" content="Tubes over XMPP" /><meta name="DC.Creator" content="Simon McVittie" /><meta name="DC.Creator" content="Alban Crequy" /><meta name="DC.Creator" content="Robert McQueen" /><meta name="DC.Description" content="A protocol for extensible collaboration over XMPP, designed specifically to implement Telepathy Tubes." /><meta name="DC.Publisher" content="XMPP Standards Foundation" /><meta name="DC.Contributor" content="XMPP Extensions Editor" /><meta name="DC.Date" content="2008-12-14" /><meta name="DC.Type" content="XMPP Extension Protocol" /><meta name="DC.Format" content="XHTML" /><meta name="DC.Identifier" content="XEP-proto-tubes" /><meta name="DC.Language" content="en" /><meta name="DC.Rights" content="" /></head><body onload="prettyPrint()"><h1>XEP-proto-tubes: Tubes over XMPP</h1><table><tr valign="top"><td><strong>Abstract:</strong></td><td>A protocol for extensible collaboration over XMPP, designed
specifically to implement Telepathy Tubes.</td></tr><tr valign="top"><td><strong>Authors:</strong></td><td>Simon McVittie, Alban Crequy, Robert McQueen</td></tr><tr valign="top"><td><strong>Copyright:</strong></td><td>© 1999 - 2009 XMPP Standards Foundation. <a href="#appendix-legal">SEE LEGAL NOTICES</a>.</td></tr><tr valign="top"><td><strong>Status:</strong></td><td>ProtoXEP</td></tr><tr valign="top"><td><strong>Type:</strong></td><td>External extension</td></tr><tr valign="top"><td><strong>Version:</strong></td><td>Gabble 0.7.17</td></tr><tr valign="top"><td><strong>Last Updated:</strong></td><td>2008-12-14</td></tr></table><hr /><p style="color:red">WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <<a href="http://xmpp.org/extensions/">http://xmpp.org/extensions/</a>> and announced on the <standards@xmpp.org> mailing list.</p><hr /><h2>Table of Contents</h2><div class="indent"><p><br />1. <a href="#intro">Introduction</a><br />2. <a href="#reqs">Requirements</a><br />3. <a href="#usecases">Use Cases</a><br />
3.1. <a href="#usecases-muc">In a multi-user chat</a><br />
3.2. <a href="#usecases-p2p">Peer to peer</a><br />
3.3. <a href="#usecases-llmuc">In a link-local multi-user chat</a><br />4. <a href="#caps">Tube capability</a><br />
4.1. <a href="#caps-general">Global tube capability</a><br />
4.2. <a href="#caps-specific">Specific tube capability</a><br />5. <a href="#rules">Business Rules</a><br />
5.1. <a href="#sect-idp34254944">D-Bus unique names in a MUC context</a><br />
5.2. <a href="#sect-idp34263200">D-Bus unique names in a link-local MUC context</a><br />
5.3. <a href="#sect-idp34265072">Definition of the tubes SI profile</a><br />
5.4. <a href="#sect-idp34269216">Parameter types</a><br />
5.5. <a href="#sect-idp34274144">TODO</a><br />6. <a href="#security">Security Considerations</a><br />7. <a href="#iana">IANA Considerations</a><br />8. <a href="#registrar">XMPP Registrar Considerations</a><br />9. <a href="#schema">XML Schema</a><br />10. <a href="#sect-idp34280896">Appendix: test data for D-Bus unique name algorithm</a></p><p><a href="#appendices">Appendices</a><br /> <a href="#appendix-docinfo">A: Document Information</a><br /> <a href="#appendix-authorinfo">B: Author Information</a><br /> <a href="#appendix-legal">C: Legal Notices</a><br /> <a href="#appendix-xmpp">D: Relation to XMPP</a><br /> <a href="#appendix-discuss">E: Discussion Venue</a><br /> <a href="#appendix-conformance">F: Requirements Conformance</a><br /> <a href="#appendix-notes">G: Notes</a><br /> <a href="#appendix-revs">H: Revision History</a></p></div><hr /><h2>1.
<a name="intro" id="intro">Introduction</a></h2>
<p>The XML namespace defined here is http://telepathy.freedesktop.org/xmpp/tubes (NS_TUBES in the
telepathy-gabble source code).</p>
<h2>2.
<a name="reqs" id="reqs">Requirements</a></h2>
<p>The Telepathy project defines an API called Tubes to be used by
arbitrary collaborative applications to communicate with instant
messaging contacts. This API is intended to be the same for several
IM protocols.</p>
<p>Tubes can be used in two types of context, referred to in Telepathy
as Tubes channels:</p>
<ul>
<li>In a multi-user chat room (on XMPP this means XEP-0045) - each
MUC may have a tubes channel</li>
<li>On a peer-to-peer basis - each pair of contacts may have a Tubes
channel</li>
</ul>
<p>Each tube has a service name, used to dispatch it to an appropriate
client application, and some essentially arbitrary parameters understood
by that client application. The tube's initiator (the contact who
started it) must also be tracked.</p>
<p>The following tube types are currently supported:</p>
<ul>
<li>D-Bus - a D-Bus message stream. In a MUC context this behaves like
the D-Bus bus daemon, so participants can send each other private
messages, or can send broadcast messages which are received by everyone
in the MUC (including themselves). Each MUC participant has a D-Bus
unique name. In a 1-1 context this behaves like a peer-to-peer
D-Bus connection - arbitrary D-Bus messages can be sent by each
participant and are received by the other participant.</li>
<li>Stream - a TCP-like bytestream. The initiator exports a service
using a listening socket. The other participant(s) can open one or more
reliable stream connections which are forwarded through the instant
messaging protocol as (possibly out-of-band) bytestreams.</li>
</ul>
<p>As well as sending and receiving data, the following operations are
supported:</p>
<ul>
<li>List the tubes available in this Tubes channel, including their
initiator, type, service, parameters and state</li>
<li>List the unique-names corresponding to the contacts (JIDs) in a
D-Bus tube, if it's in a MUC channel</li>
</ul>
<h2>3.
<a name="usecases" id="usecases">Use Cases</a></h2>
<div class="indent"><h3>3.1 <a name="usecases-muc" id="usecases-muc">In a multi-user chat</a></h3>
<p class="caption"><a name="example-1" id="example-1"></a>Example 1. Offering a new D-Bus tube</p><div class="indent"><pre class="prettyprint">
<!-- The first witch offers a D-Bus tube to the service
lit.macbeth.BubblingCauldron.
The tube parameters provided via the Telepathy API are (in dbus-python
notation):
{
's': 'hello', # string
'ay': dbus.ByteArray('hello'), # byte-array
'u': dbus.UInt32(123), # unsigned Int32
'i': dbus.Int32(-123), # signed Int32
}
See below for how the dbus-name is generated.
-->
<presence to='darkcave@conf.macbeth.lit'
from='darkcave@conf.macbeth.lit/FirstWitch'>
<x xmlns='http://jabber.org/protocol/muc'>
</x>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<tube type='dbus' initiator='darkcave@conf.macbeth.lit/FirstWitch'
service='lit.macbeth.BubblingCauldron' stream-id='12345'
id='54321' dbus-name=':2.Rmlyc3RXaXRjaAAA'>
<parameters>
<parameter name='s' type='str'>hello</parameter>
<parameter name='ay' type='bytes'>aGVsbG8=</parameter>
<parameter name='u' type='uint'>123</parameter>
<parameter name='i' type='int'>-123</parameter>
</parameters>
</tube>
</tubes>
</presence>
</pre></div>
<p class="caption"><a name="example-2" id="example-2"></a>Example 2. Accepting (joining) a D-Bus tube</p><div class="indent"><pre class="prettyprint">
<!-- The second witch accepts the tube by copying it into her own
MUC presence, changing the dbus-name to an arbitrary value
that nobody else is using. -->
<presence to='darkcave@conf.macbeth.lit'
from='darkcave@conf.macbeth.lit/Second witch'>
<x xmlns='http://jabber.org/protocol/muc'>
</x>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<tube type='dbus' initiator='darkcave@conf.macbeth.lit/FirstWitch'
service='lit.macbeth.BubblingCauldron' stream-id='12345'
id='54321' dbus-name=':2.U2Vjb25kIHdpdGNo'>
<parameters>
<parameter name='s' type='str'>hello</parameter>
<parameter name='ay' type='bytes'>aGVsbG8=</parameter>
<parameter name='u' type='uint'>123</parameter>
<parameter name='i' type='int'>-123</parameter>
</parameters>
</tube>
</tubes>
</presence>
</pre></div>
<p class="caption"><a name="example-3" id="example-3"></a>Example 3. Sending data in a MUC D-Bus tube</p><div class="indent"><pre class="prettyprint">
<!-- The second witch sends a D-Bus signal to everyone.
MUC D-Bus tubes always use MUC Bytestreams (XEP-proto-muc-bytestream).
Messages can also go to a particular participant (for method calls and
replies), and can be split up if too big - see the MUC Bytestreams
document for details.
In the serialized D-Bus message, the sender field will be
":2.U2Vjb25kIHdpdGNo". If the message was being sent to the first witch only
rather than to all participants, its destination field would be
":2.Rmlyc3RXaXRjaAAA".
The 'sid' here is the same as the 'stream-id' in the <tube> announcement.
-->
<message to='darkcave@conf.macbeth.lit'
from='darkcave@conf.macbeth.lit/Second witch'>
<data xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestreams'
sid="12345">base64base64...</data>
</message>
</pre></div>
<p class="caption"><a name="example-4" id="example-4"></a>Example 4. Offering a new stream tube</p><div class="indent"><pre class="prettyprint">
<!-- The second witch also offers a stream tube to her WebDAV server. -->
<presence to='darkcave@conf.macbeth.lit'
from='darkcave@conf.macbeth.lit/Second witch'>
<x xmlns='http://jabber.org/protocol/muc'>
</x>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<!-- This D-Bus tube is still here from the first example -
it's not part of the stream tube -->
<tube type='dbus' initiator='darkcave@conf.macbeth.lit/FirstWitch'
service='lit.macbeth.BubblingCauldron' stream-id='12345'
id='54321' dbus-name=':2.U2Vjb25kIHdpdGNo'>
<parameters>
<parameter name='s' type='str'>hello</parameter>
<parameter name='ay' type='bytes'>aGVsbG8=</parameter>
<parameter name='u' type='uint'>123</parameter>
<parameter name='i' type='int'>-123</parameter>
</parameters>
</tube>
<!-- This is the new stream tube. There is no initiator attribute
because the initiator is implicitly the participant whose presence
it's seen in -->
<tube type='stream' service='webdav' id='666'>
<parameters>
<parameter name='u' type='str'>anonymous</parameter>
<parameter name='p' type='str'>password</parameter>
<parameter name='path' type='str'>/plots/macbeth</parameter>
</parameters>
</tube>
</tubes>
</presence>
</pre></div>
<p class="caption"><a name="example-5" id="example-5"></a>Example 5. Accepting (joining) a stream tube</p><div class="indent"><pre class="prettyprint">
<!-- The first witch makes a connection to the second witch to
open the stream. Data transfer proceeds as usual according to
Stream Initiation - in this case, they'll use IBB.
The child element is <muc-stream> and not <stream> in order to
disambiguate between SI-based streams in a MUC Tubes channel, and
SI-based streams in a 1-1 channel between two members of a MUC.
The first witch MUST NOT copy the tube into her own presence
in this case - only the initiator should put stream tubes in their
presence, since stream tubes cannot continue after the initiator leaves.
-->
<iq from='darkcave@conf.macbeth.lit/FirstWitch'
to='darkcave@conf.macbeth.lit/Second witch' type='set'>
<si xmlns='http://jabber.org/protocol/si' id='55555'
profile='http://telepathy.freedesktop.org/xmpp/tubes'>
<muc-stream
xmlns='http://telepathy.freedesktop.org/xmpp/tubes'
tube='666' />
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns="jabber:x:data" type="form">
<field var='stream-method' type='list-single'>
<option>
<value>http://jabber.org/protocol/ibb</value>
</option>
</field>
</x>
</feature>
</si>
</iq>
<!-- The second witch acknowledges the IQ and data transfer proceeds
using stream ID 55555 (not shown here, but it's the same as for normal
IBB-over-SI). -->
</pre></div>
<p class="caption"><a name="example-6" id="example-6"></a>Example 6. Leaving a tube explicitly</p><div class="indent"><pre class="prettyprint">
<!-- The second witch stops offering the stream tube.
She SHOULD close the stream first, if possible - assume this has
already been done. -->
<presence to='darkcave@conf.macbeth.lit'
from='darkcave@conf.macbeth.lit/Second witch'>
<x xmlns='http://jabber.org/protocol/muc'>
</x>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<tube type='dbus' initiator='darkcave@conf.macbeth.lit/FirstWitch'
service='lit.macbeth.BubblingCauldron' stream-id='12345'
id='54321' dbus-name=':2.Rmlyc3RXaXRjaAAA'>
<parameters>
<parameter name='s' type='str'>hello</parameter>
<parameter name='ay' type='bytes'>aGVsbG8=</parameter>
<parameter name='u' type='uint'>123</parameter>
<parameter name='i' type='int'>-123</parameter>
</parameters>
</tube>
</tubes>
</presence>
</pre></div>
<p>Leaving the MUC also implicitly implies leaving all tubes.</p>
</div>
<div class="indent"><h3>3.2 <a name="usecases-p2p" id="usecases-p2p">Peer to peer</a></h3>
<p class="caption"><a name="example-7" id="example-7"></a>Example 7. Offering a new D-Bus tube</p><div class="indent"><pre class="prettyprint">
<!-- Romeo offers Tybalt a D-Bus tube to the (hypothetical) service
com.example.Chess.
The tube parameters provided via the Telepathy API are (in dbus-python
notation):
{
'theme': 'montagues-vs-capulets.conf' # string
}
-->
<iq to='tybalt@capulet.lit/Work'
from='romeo@montague.lit/Home' type='set'>
<si xmlns='http://jabber.org/protocol/si' id='chess-stream-1'
profile='http://telepathy.freedesktop.org/xmpp/tubes'>
<tube xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
type='dbus' service='com.example.Chess' id='333'>
<parameters>
<parameter name='theme'
type='str'>montagues-vs-capulets.conf</parameter>
</parameters>
</tube>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns="jabber:x:data" type="form">
<field var='stream-method' type='list-single'>
<option>
<value>http://jabber.org/protocol/ibb</value>
</option>
</field>
</x>
</feature>
</si>
</iq>
</pre></div>
<p class="caption"><a name="example-8" id="example-8"></a>Example 8. Accepting (joining) a D-Bus tube</p><div class="indent"><pre class="prettyprint">
<!-- Tybalt accepts the tube by accepting the SI -->
<iq to='romeo@montague.lit/Home'
from='tybalt@capulet.lit/Work' type='result'>
<si xmlns='http://jabber.org/protocol/si'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='stream=method'>
<value>http://jabber.org/protocol/ibb</value>
</field>
</x>
</feature>
</si>
</iq>
<!-- Messages are now sent using whatever stream protocol was
negotiated, in this case IBB. Implementations MUST NOT assume that
message boundaries are preserved. Implementations MAY preserve message
boundaries.
-->
</pre></div>
<p class="caption"><a name="example-9" id="example-9"></a>Example 9. Offering a new stream tube</p><div class="indent"><pre class="prettyprint">
<!-- Romeo offers Juliet a D-Bus tube to a private web server
The tube parameters provided via the Telepathy API are (in dbus-python
notation):
{
'path': '/poetry/for-juliet/' # string
}
-->
<message to='juliet@capulet.lit/Balcony'
from='romeo@montague.lit/Home'>
<tube xmlns='http://telepathy.freedesktop.org/xmpp/tubes'
type='stream' service='http' id='1402'>
<parameters>
<parameter name='path' type='str'>/poetry/for-juliet/</parameter>
</parameters>
</tube>
</message>
</pre></div>
<p class="caption"><a name="example-10" id="example-10"></a>Example 10. Accepting (joining) a stream tube</p><div class="indent"><pre class="prettyprint">
<!-- Juliet's web browser connects to Juliet's XMPP implementation,
causing a stream to be opened -->
<iq to='romeo@montague.lit/Home'
from='juliet@capulet.lit/Balcony' type='set'>
<si xmlns='http://jabber.org/protocol/si' id='http-stream-1a'
profile='http://telepathy.freedesktop.org/xmpp/tubes'>
<stream xmlns='http://telepathy.freedesktop.org/xmpp/tubes'
tube='1402'/>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns="jabber:x:data" type="form">
<field var='stream-method' type='list-single'>
<option>
<value>http://jabber.org/protocol/ibb</value>
</option>
</field>
</x>
</feature>
</si>
</iq>
<!-- Romeo's XMPP implementation accepts the incoming connection
and routes it to his web server -->
<iq to='juliet@capulet.lit/Balcony'
from='romeo@montague.lit/Home' type='result'>
<si xmlns='http://jabber.org/protocol/si'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='stream=method'>
<value>http://jabber.org/protocol/ibb</value>
</field>
</x>
</feature>
</si>
</iq>
<!-- Messages are now sent using whatever stream protocol was
negotiated, in this case IBB. -->
</pre></div>
<p>If Juliet's web browser opens multiple parallel connections to her
XMPP implementation, the implementation will open multiple parallel
SI streams as shown above, and Romeo's XMPP implementation will open
multiple parallel connections to his web server. This MUST be
supported by implementations.</p>
<p class="caption"><a name="example-11" id="example-11"></a>Example 11. Leaving a tube (initiator)</p><div class="indent"><pre class="prettyprint">
<!-- Romeo stops offering the stream tube.
He SHOULD close all streams first. If not, Juliet SHOULD
close all streams when this message is received. -->
<message to='juliet@capulet.lit/Balcony'
from='romeo@montague.lit/Home'>
<close xmlns='http://telepathy.freedesktop.org/xmpp/tubes'
tube='1402'/>
</message>
</pre></div>
<p class="caption"><a name="example-12" id="example-12"></a>Example 12. Leaving a tube (non-initiator)</p><div class="indent"><pre class="prettyprint">
<!-- Alternatively, Juliet could reject the stream tube.
She SHOULD close all streams first. If not, Romeo SHOULD close all
streams in response to this message. -->
<message from='juliet@capulet.lit/Balcony'
to='romeo@montague.lit/Home'>
<close xmlns='http://telepathy.freedesktop.org/xmpp/tubes'
tube='1402'/>
</message>
</pre></div>
<p>Only stream tubes use a message stanza to be closed. D-Bus tubes are
closed implicitly when the underlying bytestream is closed and thus do
not need an explicit message stanza.</p>
</div>
<div class="indent"><h3>3.3 <a name="usecases-llmuc" id="usecases-llmuc">In a link-local multi-user chat</a></h3>
<p class="caption"><a name="example-13" id="example-13"></a>Example 13. Offering a new D-Bus tube</p><div class="indent"><pre class="prettyprint">
<!-- Suppose Mercutio and Tybalt are in a link-local chatroom,
with their mDNS presence records being
mercutio@mab._presence._tcp.local. and
Tybalt@feline._presence._tcp.local.
Mercutio offers a D-Bus tube to the service lit.verona.Duel.
This time one Tube parameter was provided by the Telepathy API,
a string called 'weapon' with value "swords".
See below for how the dbus-name is generated.
-->
<!-- Sent by mercutio@mab -->
<message type='groupchat'>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<tube type='dbus' initiator='mercutio@mab'
service='lit.verona.Duel' stream-id='8'
id='54321' dbus-name=':2.bWVyY3V0aW9AbWFi'>
<parameters>
<parameter name='weapon' type='str'>swords</parameter>
</parameters>
</tube>
</tubes>
</message>
</pre></div>
<p class="caption"><a name="example-14" id="example-14"></a>Example 14. Accepting (joining) a D-Bus tube</p><div class="indent"><pre class="prettyprint">
<!-- Tybalt joins the D-Bus tube, changing the dbus-name appropriately.
In the implementation of Tubes on link-local MUC he may also have a
different stream-id. -->
<!-- Sent by Tybalt@feline -->
<message type='groupchat'>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<tube type='dbus' initiator='mercutio@mab'
service='lit.macbeth.BubblingCauldron' stream-id='6'
id='54321' dbus-name=':2.VHliYWx0QGZlbGluZQAA'>
<parameters>
<parameter name='weapon' type='str'>swords</parameter>
</parameters>
</tube>
</tubes>
</message>
</pre></div>
<p class="caption"><a name="example-15" id="example-15"></a>Example 15. Sending data in a link-local MUC D-Bus tube</p><div class="indent"><pre class="prettyprint">
<!-- Tybalt sends a D-Bus message and Mercutio responds.
Link-local MUC D-Bus tubes always use the rMulticast streams 1 to 255;
in this case, because Tybalt has stream-id='6' in his announcement
message, all messages from Tybalt in stream 6 MUST be interpreted as
part of tube 54321. Similarly, all messages from Mercutio in stream 8
MUST be interpreted as part of tube 54321. Messages from Tybalt in
stream 8 are NOT part of tube 54321.
-->
<!-- (a binary rMulticast message is sent by Tybalt with stream ID 6;
its payload is a raw D-Bus message) -->
<!-- (a binary rMulticast message is sent by Mercutio with stream ID 8;
its payload is also a raw D-Bus message) -->
</pre></div>
<p class="caption"><a name="example-16" id="example-16"></a>Example 16. Joining and being notified about link-local MUC tubes</p><div class="indent"><pre class="prettyprint">
<!-- An rMulticast join event occurs, in which Romeo and Benvolio
join the chatroom. Their mDNS presence records are:
romeo@angstbook._presence._tcp.local.
benvolio@peacemaker._presence._tcp.local.
Mercutio and Tybalt must both respond by re-sending
their tube announcements to the chatroom, once. They SHOULD NOT
send their tube announcements twice when two participants join
in a single join event. -->
<!-- rMulticast protocol indicates that romeo@angstbook and
benvolio@peacemaker have joined the room -->
<!-- Sent by mercutio@mab -->
<message type='groupchat'>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<tube type='dbus' initiator='mercutio@mab'
service='lit.verona.Duel' stream-id='8'
id='54321' dbus-name=':2.bWVyY3V0aW9AbWFi'>
<parameters>
<parameter name='weapon' type='str'>swords</parameter>
</parameters>
</tube>
</tubes>
</message>
<!-- Sent by Tybalt@feline -->
<message type='groupchat'>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<tube type='dbus' initiator='mercutio@mab'
service='lit.verona.Duel' stream-id='6'
id='54321' dbus-name=':2.VHliYWx0QGZlbGluZQAA'>
<parameters>
<parameter name='weapon' type='str'>swords</parameter>
</parameters>
</tube>
</tubes>
</message>
</pre></div>
<p class="caption"><a name="example-17" id="example-17"></a>Example 17. Offering a new stream tube</p><div class="indent"><pre class="prettyprint">
<!-- Mercutio offers a stream tube to his WebDAV server. This message
would also be re-sent if another rMulticast join event occurred. -->
<message type='groupchat'>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<!-- This D-Bus tube is still here from the first example -
it's not part of the stream tube -->
<tube type='dbus' initiator='mercutio@mab'
service='lit.verona.Duel' stream-id='8'
id='54321' dbus-name=':2.bWVyY3V0aW9AbWFi'>
<parameters>
<parameter name='weapon' type='str'>swords</parameter>
</parameters>
</tube>
<!-- This is the new stream tube. There is no initiator attribute
because the initiator is implicitly the participant whose message
it's seen in -->
<tube type='stream' service='webdav' id='666'>
<parameters>
<parameter name='path' type='str'>/warez</parameter>
</parameters>
</tube>
</tubes>
</presence>
</pre></div>
<p class="caption"><a name="example-18" id="example-18"></a>Example 18. Accepting (joining) a stream tube</p><div class="indent"><pre class="prettyprint">
<!-- Romeo joins the stream tube to download some MP3s from
Mercutio's server.
The child element is, again, <muc-stream> and not <stream>.
Romeo MUST NOT copy the tube into his own tube announcements
in this case - only the initiator should announce stream tubes,
since stream tubes cannot continue after the initiator leaves.
-->
<!-- Sent by romeo@angstbook -->
<iq to='mercutio@mab' type='set'>
<si xmlns='http://jabber.org/protocol/si' id='55555'
profile='http://telepathy.freedesktop.org/xmpp/tubes'>
<muc-stream
xmlns='http://telepathy.freedesktop.org/xmpp/tubes'
tube='666' />
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns="jabber:x:data" type="form">
<field var='stream-method' type='list-single'>
<option>
<value>jabber:iq:oob</value>
</option>
</field>
</x>
</feature>
</si>
</iq>
<!-- Sent by mercutio@mab -->
<iq to='romeo@angstbook' type='result'>
<si xmlns='http://jabber.org/protocol/si' id='55555'
profile='http://telepathy.freedesktop.org/xmpp/tubes'>
<muc-stream xmlns='http://telepathy.freedesktop.org/xmpp/tubes'
tube='666'/>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='stream-method'>
<value>jabber:iq:oob</value>
</field>
</x>
</feature>
</si>
</iq>
<!-- Sent by romeo@angstbook -->
<iq to='mercutio@mab' type='set'>
<query xmlns='jabber:iq:oob' sid='55555'>
<url>x-tcp://angstbook.local:1234</url>
</query>
</iq>
<!-- Mercutio resolves the IP address of angstbook.local and connects
to port 1234, and out-of-band transfer proceeds -->
<!-- FIXME: this has too many steps and it ends up with a TCP
connection flowing "the wrong way" -->
</pre></div>
<p class="caption"><a name="example-19" id="example-19"></a>Example 19. Leaving a tube explicitly</p><div class="indent"><pre class="prettyprint">
<!-- Mercutio stops offering the stream tube.
He SHOULD close the OOB stream first, if possible - assume this has
already been done. -->
<message type='groupchat'>
<tubes xmlns='http://telepathy.freedesktop.org/xmpp/tubes'>
<!-- This D-Bus tube is still here from the first example -
it's now the only one, because the stream tube has been
removed -->
<tube type='dbus' initiator='mercutio@mab'
service='lit.verona.Duel' stream-id='8'
id='54321' dbus-name=':2.bWVyY3V0aW9AbWFi'>
<parameters>
<parameter name='weapon' type='str'>swords</parameter>
</parameters>
</tube>
</tubes>
</message>
</pre></div>
<p>Leaving the link-local MUC (a leave or split event from rMulticast)
also implicitly implies leaving all tubes.</p>
</div>
<h2>4.
<a name="caps" id="caps">Tube capability</a></h2>
<div class="indent"><h3>4.1 <a name="caps-general" id="caps-general">Global tube capability</a></h3>
<p>The tube feature is advertised with XEP-0115 Entity Capabilities using
this string:</p>
<p class="caption"></p><div class="indent"><pre class="prettyprint">http://telepathy.freedesktop.org/xmpp/tubes</pre></div>
</div>
<div class="indent"><h3>4.2 <a name="caps-specific" id="caps-specific">Specific tube capability</a></h3>
<p>We want to know which tube the contacts can handle. There is two
different kind of tube capabilities:</p>
<ul>
<li>Can my contact receive a tube offer of a specific service?</li>
<li>Can my contact offer a tube of a specific service?</li>
</ul>
<p>Only the first kind is considered. The second is out of scope of this
specification. Each specific service is advertised with XEP-0115 Entity
Capabilities with this string:</p>
<p class="caption"></p><div class="indent"><pre class="prettyprint">http://telepathy.freedesktop.org/xmpp/tubes/$type#$service</pre></div>
<p>where $type is the tube type (either "dbus" or "stream") and $service is
the service name (e.g. "vnc" or "TicTacTube").</p>
</div>
<h2>5.
<a name="rules" id="rules">Business Rules</a></h2>
<div class="indent"><h3>5.1 <a name="sect-idp34254944" id="sect-idp34254944">D-Bus unique names in a MUC context</a></h3>
<p>The D-Bus unique names used in the MUC SHOULD be ":2." followed by the
MUC nick (i.e. the resource part of the MUC JID) processed with the
following algorithm:</p>
<ul>
<li>Let utf8nick be the MUC nick encoded using UTF-8</li>
<li>If utf8nick has 186 octets or fewer, encode it using
Base64; otherwise encode a string consisting of the first 169
octets of utf8nick, followed by the 20 octets of the
SHA-1 of utf8nick (note that this is the whole of the raw
binary SHA-1, and not the first half of the SHA-1 written in
hexadecimal).</li>
<li>Remove all whitespace</li>
<li>Replace "+" with "_", "/" with "-" and "=" with "A"</li>
</ul>
<p>This produces collision-free unique names of length no more than 251
octets (4/3 * 186 + 3) for nicknames no longer than 186 UTF-8 octets
(replacing "=" with "A" is harmless here because XMPP resources cannot
contain U+0000).</p>
<p>For longer nicknames it makes collisions highly unlikely, and produces
255-octet unique names (4/3 * 189 + 3), which still fit into D-Bus'
255-octet limit.</p>
<p>The choice of 186 and 169 for the magic numbers ensures that these long
nicknames can only have unique-name collisions with other long
nicknames, and that the Base64 encoding step when applied to long
nicknames does not leave any trailing "=" characters.</p>
<p>Implementations MUST NOT use unique names that start with ":2." but are
not formed according to the above rules, and SHOULD treat tube elements
containing such a dbus-name as if they were invalid.</p>
<p>For backwards compatibility with earlier implementations, the dbus-name
MAY also be ":1." followed by an arbitrary unique string of up to 252
characters chosen from A-Z, a-z, 0-9, "-" or "_".</p>
</div>
<div class="indent"><h3>5.2 <a name="sect-idp34263200" id="sect-idp34263200">D-Bus unique names in a link-local MUC context</a></h3>
<p>The D-Bus unique names used in a link-local MUC SHOULD be ":2."
followed by the _presence._tcp instance name (e.g. mercutio@mab)
processed with the algorithm above.</p>
<p>Again, implementations MUST NOT use unique names that start with ":2."
but are not formed according to the above rules, and SHOULD treat tube
elements containing such a dbus-name as if they were invalid.</p>
</div>
<div class="indent"><h3>5.3 <a name="sect-idp34265072" id="sect-idp34265072">Definition of the tubes SI profile</a></h3>
<p>The Tubes SI profile is indicated by the profile string http://telepathy.freedesktop.org/xmpp/tubes.
A Tubes SI IQ can be classified as follows:</p>
<ul>
<li>If the IQ contains a <tube> element with the namespace
http://telepathy.freedesktop.org/xmpp/tubes, then the IQ represents a new tube being offered.</li>
<li>If the IQ contains a <stream> element with the namespace
http://telepathy.freedesktop.org/xmpp/tubes, then the IQ represents a new connection to an existing
stream tube in a 1-1 Tubes channel.</li>
<li>If the IQ contains a <muc-stream> element with the namespace
http://telepathy.freedesktop.org/xmpp/tubes, then the IQ represents a new connection to an existing
stream tube in a MUC Tubes channel - this message type is invalid
and must be rejected unless received via a MUC.</li>
<li>Otherwise, the SI is invalid and MUST be rejected.</li>
</ul>
</div>
<div class="indent"><h3>5.4 <a name="sect-idp34269216" id="sect-idp34269216">Parameter types</a></h3>
<p>The allowed parameter types are:</p>
<ul>
<li>"str": A Unicode string containing no zero bytes '\0'. In this
implementation it cannot contain any other character forbidden
by XML either. The <parameter> character content is the
string itself. The corresponding D-Bus signature is 's'.
This corresponds to xs:string in XML Schema Part 2.</li>
<li>"bytes": An array of bytes, represented in Base64. The corresponding
D-Bus signature is 'ay'. This corresponds to xs:base64Binary in
XML Schema Part 2.</li>
<li>"uint": An unsigned integer representable in 32 bits. The
corresponding D-Bus signature is 'u' or 'q' on input, 'u' on output.
The element's character content is an ASCII unsigned
decimal integer. This corresponds to xs:unsignedInt in XML
Schema Part 2.</li>
<li>"int": A signed integer representable in 32 bits using two's
complement. The corresponding D-Bus signature is 'i' or 'n' on input,
'i' on output, and the element's character content is an ASCII
decimal integer, possibly starting with '-' or '+'. This corresponds
to xs:int in XML Schema Part 2.</li>
<li>"bool": A boolean value represented as one of the strings "false",
"true", "0" or "1", as per xs:boolean in XML Schema Part 2.
The corresponding D-Bus signature is 'b'. (Implementation note:
early versions of Tubes in Gabble only accepted "0" or "1", so
implementations that care about backwards compatibility SHOULD emit
those representations).</li>
</ul>
</div>
<div class="indent"><h3>5.5 <a name="sect-idp34274144" id="sect-idp34274144">TODO</a></h3>
<p>FIXME: how big do we want to allow a message to be? In the D-Bus
specification the limit is 2**27 bytes, in the default dbus-daemon
configuration (as used on the system bus) it's 32M.</p>
<p>FIXME: limit how many messages are queued up somehow (the system bus
limits it to 127M in total)</p>
</div>
<h2>6.
<a name="security" id="security">Security Considerations</a></h2>
<p>FIXME</p>
<h2>7.
<a name="iana" id="iana">IANA Considerations</a></h2>
<p>None.</p>
<h2>8.
<a name="registrar" id="registrar">XMPP Registrar Considerations</a></h2>
<p>None, this isn't a real XEP (yet?).</p>
<h2>9.
<a name="schema" id="schema">XML Schema</a></h2>
<p class="caption"></p><div class="indent"><pre class="prettyprint">
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://telepathy.freedesktop.org/xmpp/protocol/tubes'
xmlns='http://telepathy.freedesktop.org/xmpp/protocol/tubes'
elementFormDefault='qualified'>
<!-- Container for <tube> elements in MUC <presence> -->
<xs:element name='tubes'>
<xs:complexType>
<xs:sequence minOccurs='0'>
<xs:element ref='tube' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- A tube offer -->
<xs:element name='tube'>
<xs:complexType>
<!-- Required attributes -->
<xs:attribute name='id' type='xs:unsignedInt' use='required'/>
<xs:attribute name='type' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='dbus'/>
<xs:enumeration value='stream'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='service' type='xs:string' use='required'/>
<!-- MUC D-Bus tube attributes -->
<!-- MUST be present for MUC D-Bus tubes, SHOULD NOT be
emitted for other types of tube, MUST be ignored for other types
of tube -->
<xs:attribute name='initiator' type='xs:string' use='optional'/>
<xs:attribute name='dbus-name' type='xs:string' use='optional'/>
<xs:attribute name='stream-id' type='xs:string' use='optional'/>
<!-- Parameters -->
<xs:element name='parameters'>
<xs:sequence minOccurs='0'>
<xs:element name='parameter' minOccurs='0'
maxOccurs='unbounded' type='name-value-pair'/>
</xs:element>
</xs:sequence>
</xs:element>
</xs:complexType>
</xs:element>
<!-- A name-value pair -->
<xs:complexType name='name-value-pair'>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='name' type='xs:string'/>
<xs:attribute name='type'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='bool'/>
<xs:enumeration value='str'/>
<xs:enumeration value='bytes'/>
<xs:enumeration value='int'/>
<xs:enumeration value='uint'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name='tube-reference'>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='tube' use='required' type='xs:unsignedInt'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name='close' type='tube-reference'/>
<xs:element name='stream' type='tube-reference'/>
<!-- only valid in a MUC -->
<xs:element name='muc-stream' type='tube-reference'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</pre></div>
<h2>10.
<a name="sect-idp34280896" id="sect-idp34280896">Appendix: test data for D-Bus unique name algorithm</a></h2>
<p>The string "short" produces the unique name ":2.c2hvcnQA".</p>
<p>The string "FirstWitch", as used in the examples, produces the
unique name ":2.Rmlyc3RXaXRjaAAA".</p>
<p>The string "Second witch", as used in the examples, produces the
unique name ":2.U2Vjb25kIHdpdGNo".</p>
<p>The string consisting of 18 repetitions of "0123456789" followed by
"012345" (186 characters) produces a unique name consisting of ":2.",
followed by 6 repetitions of the 40-character string
"MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5", followed by "MDEyMzQ1".</p>
<p>The string consisting of 18 repetitions of "0123456789" followed by
"0123456" (187 characters) produces a unique name consisting of ":2.",
followed by 5 repetitions of the 40-character string above, followed by
"MDEyMzQ1Njc4OTAxMjM0NTY3OEVd9C5NgmmRD6jp1ftG6XUEc11x".</p>
<p>The string consisting of 20 repetitions of "0123456789" (200 characters)
produces a unique name consisting of ":2.", followed by 5 repetitions of
the 40-character string above, followed by
"MDEyMzQ1Njc4OTAxMjM0NTY3OO-utwRnwcoUFhnJVMKg5pm9Hxal".</p>
<hr /><a name="appendices" id="appendices"></a><h2>Appendices</h2><hr /><a name="appendix-docinfo" id="appendix-docinfo"></a><h3>Appendix A: Document Information</h3><p class="indent">
Series: <a href="http://xmpp.org/extensions/">XEP</a><br />
Number: proto-tubes<br />
Publisher: <a href="/xsf/">XMPP Standards Foundation</a><br />
Status:
<a href="http://xmpp.org/extensions/xep-0001.html#states-ProtoXEP">ProtoXEP</a><br />
Type:
<a href="http://xmpp.org/extensions/xep-0001.html#types-External extension">External extension</a><br />
Version: Gabble 0.7.17<br />
Last Updated: 2008-12-14<br />
Approving Body: <a href="http://xmpp.org/council/">XMPP Council</a><br />Dependencies: XMPP Core, XEP-0045, XEP-0047, XEP-0095, XEP-proto-muc-bytestream<br />
Supersedes: None<br />
Superseded By: None<br />
Short Name: NOT YET ASSIGNED<br /></p><hr /><a name="appendix-authorinfo" id="appendix-authorinfo"></a><h3>Appendix B: Author Information</h3><div class="indent"><h3>Simon McVittie</h3><p class="indent">
Email:
<a href="mailto:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a><br />
JabberID:
<a href="xmpp:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a><br /></p><h3>Alban Crequy</h3><p class="indent">
Email:
<a href="mailto:alban.crequy@collabora.co.uk">alban.crequy@collabora.co.uk</a><br />
JabberID:
<a href="xmpp:alban.crequy@collabora.co.uk">alban.crequy@collabora.co.uk</a><br /></p><h3>Robert McQueen</h3><p class="indent">
Email:
<a href="mailto:robert.mcqueen@collabora.co.uk">robert.mcqueen@collabora.co.uk</a><br />
JabberID:
<a href="xmpp:robert.mcqueen@collabora.co.uk">robert.mcqueen@collabora.co.uk</a><br /></p></div><hr /><a name="appendix-legal" id="appendix-legal"></a><h3>Appendix C: Legal Notices</h3><div class="indent"><h4>Copyright</h4><h4>Permissions</h4><h4>Disclaimer of Warranty</h4><span style="font-weight: bold"></span><h4>Limitation of Liability</h4><h4>IPR Conformance</h4></div><hr /><a name="appendix-xmpp" id="appendix-xmpp"></a><h3>Appendix D: Relation to XMPP</h3><p class="indent">The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.</p><hr /><a name="appendix-discuss" id="appendix-discuss"></a><h3>Appendix E: Discussion Venue</h3><p class="indent">The primary venue for discussion of XMPP Extension Protocols is the <<a href="http://mail.jabber.org/mailman/listinfo/standards">standards@xmpp.org</a>> discussion list.</p><p class="indent">Discussion on other xmpp.org discussion lists might also be appropriate; see <<a href="http://xmpp.org/about/discuss.shtml">http://xmpp.org/about/discuss.shtml</a>> for a complete list.</p><p class="indent">Errata can be sent to <<a href="mailto:editor@xmpp.org">editor@xmpp.org</a>>.</p><hr /><a name="appendix-conformance" id="appendix-conformance"></a><h3>Appendix F: Requirements Conformance</h3><p class="indent">The following requirements keywords as used in this document are to be interpreted as described in <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".</p><hr /><a name="appendix-notes" id="appendix-notes"></a><h3>Appendix G: Notes</h3><div class="indent"></div><hr /><a name="appendix-revs" id="appendix-revs"></a><h3>Appendix H: Revision History</h3><p>Note: Older versions of this specification might be available at <a href="http://xmpp.org/extensions/attic/">http://xmpp.org/extensions/attic/</a></p><div class="indent"><h4>Version Gabble 0.7.17 (2008-12-14)</h4><div class="indent">
<p>Define Tube capabilities.</p>
(ac/ram)
</div><h4>Version Gabble 0.7.0 (2007-09-27)</h4><div class="indent">
<ul>
<li>Don't copy stream tubes into MUC presence</li>
<li>Tube IDs must be numeric (uint32)</li>
<li>Don't put initiator in MUC stream tube info</li>
<li>Use a mesage-based protocol to offer 1-1 stream tubes, rather
than the weird default bytestream thing</li>
<li>Non-initiator can close 1-1 stream tubes too</li>
<li>Remove /protocol/ from namespace URI</li>
</ul>
(smcv)
</div><h4>Version 0.0.1 (2007-09-25)</h4><div class="indent"><p>First draft. Only protocol changes are listed in subsequent
proto-XEP versions.</p> (smcv)
</div></div><hr /><p>END</p></body></html>
|