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

Peter Saint-Andre stpeter at jabber.org
Fri Dec 13 18:57:29 UTC 2002


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?

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

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
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> -- 
> 
> Matt "linuxwolf" Miller
> JID:	linuxwolf at outer-planes.net
> E-MAIL:	linuxwolf at outer-planes.net
> 
> - Got "JABBER"? (http://www.jabber.org/)
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards mailing list