[standards-jig] Pondering DTCP
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards