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

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Fri Dec 13 18:40:06 UTC 2002


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/)




More information about the Standards mailing list