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

Peter Millard me at pgmillard.com
Fri Dec 13 18:22:38 UTC 2002

[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

I'm +1 for this (much more so, than either DTCP or JOBS)... looking forward
to hearing what Justin & Matt think about this proposal.


More information about the Standards mailing list