[standards-jig] A Proposal to the DTCP/JOBS/PASS madness

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Dec 13 20:50:07 UTC 2002

Jan Niehusmann <jan at gondor.com> wrote on 13-12-2002 21:33:04:
>On Fri, Dec 13, 2002 at 08:09:52PM +0100, Tijl Houtbeckers wrote:
>> I don't think you've covered the problem of establishing a generic 
>> bytestream between two peers, just by providing a way to set up an 
>> IPv4 socket between two peers. You should be able set up a generic 
>> bytestream for filetranfser or other purposes (incl. asynchronous!) 
>> regardless of wether you want to use a socket for it or not. 
>As jabber itself doesn't even need IP (it may as well be implemented
>through a serial line), every attempt to implement out-of-band
>communication is condemned to fail in some situation. 
>Additionally, out-of-band connections are against the basic principle 
>of jabber, to have a single c2s channel and leave all the routing 
>worries to the server.
>Unfortunately, real-world issues prevent the transfer of arbitrarily
>large amounts of data through the jabber servers. This is the
>fundamental reason to implement out-of-band file transfer. 
>If you only have a single network connection to use, I don't see how 
>you could create an out-of-band communication link at all, so you have 
>to live with the bandwidth limitations the server imposes.

Well, I could think of a few out-of-band communactions on a mobile 
device that could be initiated through Jabber (first to mind is 
Bluetooth / WiFi). But that's not so much my point. what I've been 
trying to point out through most of the discussion is that we need a 
framework (a JEP) for establishing bytestreams from one peer to the 
other. Wether this is done with IBB, OOB, TCP, IPv4, IPv6 or whatever 
shouldn't matter. It should be a *true* generic framework. 

On the basis of *that* JEP there can be other JEP's like DTCP, JOBS, 
PASS, IBB, Bluetooth, Postal Pigeons, and whatever is proposed now. On 
the other side there are the JEPs like filetransfer, etc. 

What is being proposed here is being presented (by some) as a generic 
framework but it's not, it's only generic for TCP sockets and possibly 

The most needed thing besides a TCP based stream IMHO is IBB. Apart 
from that a fast-unreliable method (most likely based on UDP ofcourse) 
and an encrypted way of transfering. Enough possibilities for various 
degrees of security should be possible in the framework. 

Besides these methods there is ofcourse still room for more excentric 
things like: reliable transfer over UDP for faster transfer and to 
allow setting up a stream without a proxy when both parties are behind 
a NAT, WiFi/Bluetooth, JXTA and postal pigeons :) 

If something like this could be realised on of Jabber's real-world 
weakness would become just another one of it's strengths. Judging by 
the reactions on the list though I have my doubt that everyone agrees 
with me on this. 

Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list