[standards-jig] Pondering DTCP

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Dec 13 02:13:46 UTC 2002

Thomas Muldowney <temas at box5.net> wrote on 13-12-2002 2:44:53:
>I want to first reply only about JidLink.  I completely disagree that
>JidLink solves any kind of problem for negotiating a connection.  In
>fact it is just feature negotiation, so why not use feature negotiation
>direclty like we did in file transfer.  The reason that it doesn't
>really solve anything is the lack of immediate context.  I'm not going
>to send a JidLink list to someone that includes iq:oob when I'm
>negotiating a VoIP connection.  I only want to send him the valid
>options for our specific task.  More so, I want it in my negotiation
>with all the other options related to it.  Look at file transfer, the
>user is better able to pick the transfer method because they 
>immediately have available information such as name, size, and mime-
>type.  I'm not creating a system where we have to have 3 or 4 back-and-
>forths before we've established all the exacts.  Unless I can be shown 
>otherwise, I don't see how JidLink is solving the problem set in an 
>efficient manner. 

I don't see how things like MIME-type and name of the file have to 
affect the way a file is send. I think there should be a framework in 
Jabber for transfering data out of band from one peer to the other. I 
don't think that when I implent filetransfer I should be concered with 
who connects to who, wich NAT is where, and wether UDP, TCP or ICMP-
over-TCP/IP-over-HTTP-over-DNS is used. 

Jabber is very strong in transporting XML data C2S(2C) or C2S2S(2C). 
Jabber right now is very weak in transporting binary data, and 
transporting data peer to peer, espc. asynchronous. A framework to 
address this need would be a great step forward (up to World 
Domination! ;). If for every JEP that does something that could be done 
by this framework we start all over again, just for the purpose of that 
JEP this will continue to be a weak spot in the Jabber model. 

I'm not saying it has to be JidLink in it's current form, or that it 
can't use feature negotiation. I'm just saying there *should* be a 
framework like this, and other JEPs should not duplicate it's work. 

All that should be in a filetransfer JEP or an remote-acces-through-RFB 
JEP etc. should be what kind of JidLink is required: Should it be 
reliable, unreliable or a form of realiable-secure? Is the link 
required to be near realtime and/or asynchronous? And possibly, is the 
link allowed to be "inband"? 

After that the JidLink JEP should take care of providing the best 
available "link". Wether the data in the end is transferred by HTTP, 
DTCP, JXTA, Postal Pigeons or through Google's cache shouldn't matter 
in the end. It's better as not having your data transfered :) 

This is all IMHO ofcourse, but I fail to see how such a thing could be 
bad for Jabber in the long run. 

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

More information about the Standards mailing list