[standards-jig] Pondering DTCP

Thomas Muldowney temas at box5.net
Fri Dec 13 03:07:03 UTC 2002


I think your missing my point.  It was a criticism of JidLink as the
piece to provide the negotiation of some connection.  I'm saying it's
feature-negotiation of a feature-negotiation and that it should be
inlined like file transfer.  Talking of mime-type and name was an
example, maybe for certain mime-types I use a certain method, maybe for
high priority docs I use a 100% reliable (HAH ;-]) method, but the point
was that the information along side the negotiation could be extremely
beneficial.

--temas


On Fri, Dec 13, 2002 at 03:13:46AM +0100, Tijl Houtbeckers wrote:
> 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
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20021212/b060e5dd/attachment.sig>


More information about the Standards mailing list