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

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Dec 13 19:09:52 UTC 2002


Peter Saint-Andre <stpeter at jabber.org> wrote on 13-12-2002 19:57:29:
>
>One concern might be for certain clients that simply cannot open 
>another TCP connection, since only one is allowed (I know Tijl brought 
>this up at JabberConf in Munich earlier this year with regard to 
>certain portable devices). I'm not sure where such clients fit in 
>here, although the same concern might apply to other proposals as well.
>
>Tijl?
>

Thanks Peter,
You've rembered correctly :) Additionally there will be lot's of 
situations that applications are restricted (eg. through signing of 
applications) in wich host/IP/port they can connect to. Ofcourse that 
doesn't just apply to the mobile/embedded world. 

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. 

>
>On 13 Dec 2002, Matthew A. Miller wrote:
>
>> I'm +1 for this.  There's minor nit-picks (e.g. allowance for DNS
>> hostnames rather than just IPs), but it's sound and straightforward.
>> 
>> 
>> -  LW
>> 
>> On Fri, 2002-12-13 at 10:22, Peter Millard wrote:
>> > [Lots of stuff snipped from D. Smith aka dizzyd]
>> > 
>> > > ==============================================================
>> > > * This methodolgy does not require _ANY_ wire protocol on the
>> > > p2p/proxy connections. We're using Jabber as it should be used. 
>> > > This allows us to be able to pass the IP/port off to a entirely 
>> > > different process and it can speak whatever protocol is 
>> > > appropriate 
>> > 
>> > IMO, this is precisely the main issue that I've had with all other 
>> > forms of bytestreams: they were introducing yet another wire 
>> > protocol that had to be implemented in clients when there are lots 
>> > of perfectly good _STANDARDIZED_ protocols out there.
>> > 
>> > I like this proposal since it leaves the socket clean of any other
>> > protocols, and it's up to the application(s) to decide what wire 
>> > protocol is best suited for the purpose of the connection. If the 
>> > endpoints wish to do further authentication using whatever wire 
>> > protocol they decide is best, thats possible.
>> > 
>> > Some other comments though:
>> > 
>> > - If I _know_ that I'm behind a NAT or a firewall (by having the 
>> > user click [x] I'm behind a firewall in a client), the sender 
>> > should not even send it's own IP/Port out in the initial request, 
>> > it should just send the proxy. What we loose here is that I may be 
>> > trying to negotiate a stream w/ someone on my private network, but 
>> > it's basically impossible to do this in reality (even private IP 
>> > #'s don't work, since we could both be using home netoworks which 
>> > use: 192.168.1.x). 
>> > 
>> > - We should also say that jabber IM clients should always use this 
>> > mechanism for setting up file transfers between 2 clients.. AND 
>> > the wire protocol used (once the stream is established) MUST be 
>> > HTTP. This means that existing receive code can be re-used, and if 
>> > there are publicly accessable proxies, then even the double-NAT 
>> > case becomes trivial. This would then indicate that any in-band 
>> > solution becomes un-necessary (since we can always proxy). 
>> > 
>> > - This seems to efficiently solve both of the problem spaces we're 
>> > trying to find a solution: File Transfer and having some kind of 
>> > generic "byte-stream".
>> > 
>> > I'm +1 for this (much more so, than either DTCP or JOBS)... 
>> > looking forward to hearing what Justin & Matt think about this 
>> > proposal. 
>> > 
>> > pgm
>> > 
>> -- 
>> 
>> Matt "linuxwolf" Miller
>> JID:	linuxwolf at outer-planes.net
>> E-MAIL:	linuxwolf at outer-planes.net
>> 
>> - Got "JABBER"? (http://www.jabber.org/)
>> 
-- 
Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list