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

Dave Smith dizzyd at jabber.org
Fri Dec 13 23:02:47 UTC 2002

Hash: SHA1

On Friday, Dec 13, 2002, at 15:05 America/Denver, Jan Niehusmann wrote:

> On Fri, Dec 13, 2002 at 09:52:46AM -0700, Dave Smith wrote:
>> PF2.) Initiator sends its IP/port in a IQ/set to Target, accompanied 
>> by
>> a stream ID [A1]
>> PF3.) Target connects to a provided connection[A2][A5]
>> PF4.) Target sends IQ/set to the JID of the connection it is connected
>> to for identification purposes
>> 	  NOTE: The Target provides the IP/port of the _peer_ it is connected
>> to with a stream ID
> I just noticed that your proposal has another disadvantage: You can't
> use the same port to listen for more than one connection.  This is bad
> because it hinders people who are behind NAT to configure proper port
> forwarding, as the jabber client needs to listen on several ports if it
> should support more than one transfer at a time.

Huh? I don't follow your logic here, Jan. I suspect I need to clarify 
something, but I'm not sure what. What exact step do you see as 
limiting the number of connections on a single listening port?

> I don't know how to solve that problem without some handshake on the 
> connection. Does anybody have an idea? With this discussion becoming
> more and more constructive lately, I'm positive we are heading for a
> much better protocol than anyone of us could have designed alone!

The TCP connection _does not_ need any protocol. In fact, the whole 
point of this discussion is discovering a Jabber protocol that allows 
us to establish a generic TCP connection. All the necessary signaling 
can be done out-of-band (i.e. in Jabber). This has the unique advantage 
of allowing implementors of this methodology to hand off the ip/port to 
an external process so it can create it's own TCP socket independent of 
the Jabber client. Try _that_ with DTCP :)

As for HTTP, I'm fine if we want to use that for doing file transfer 
over the negotiated connection, but I want to make it clear that 
negotiating the connection itself will not require HTTP (or any other 

I do agree with you, Jan, that the discussion is much more constructive 
than it was. :)


Version: PGP 8.0 (Build 349) Beta


More information about the Standards mailing list