[standards-jig] A Proposal to the DTCP/JOBS/PASS madness
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.
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/)
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards