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

Justin Karneges justin-jdev at affinix.com
Fri Dec 13 22:35:30 UTC 2002


On Friday 13 December 2002 02:05 pm, 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.
>
> I don't know how to solve that problem without some handshake on the TCP
> 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 idea of no wire protocol is intriguing, but will avoiding one solve the 
problem?  The goal seems to be to retain the ability to use HTTP instead of 
something proprietary, but I'd go as far to say that any handshake protocol 
(even if entirely done on the Jabber side) is proprietary.  Is this any 
different/easier than feeding HTTP data immediately following a TCP 
handshake?

I don't have a problem with either way, but this lack of a handshake may be 
the cause of the issues Jan has cited.

-Justin




More information about the Standards mailing list