[standards-jig] DTCP Relay (proxy)

Dave Smith dizzyd at jabber.org
Thu Dec 12 14:40:13 UTC 2002

Hash: SHA1

On Thursday, Dec 12, 2002, at 05:53 America/Denver, Jan Niehusmann 

> - I agree that the sequencing changes are a bad idea. They remove a
>   major advantage of DTCP, and require additional negotiation on higher
>   protocol levels. That would lead to duplication of work at these 
> higher
>   levels.

What major advantage of DTCP do these changes remove? Isn't DTCP meant 
to be a foundational protocol that other protocols build on top of do 
their specific task? In other words, my understanding of DTCP is that 
it defines the bare functionality necessary to establish a bytestream 
connection to another entity -- all other negotiation should happen in 
a higher-level, application specific protocol.

> - There may be a better alternative to Justins relay proposal. There
>   already is a JEP specifying relay functionality, namely JEP-0003,
>   PASS.

Oh nelly! We're talking about bytestreams here! DTCP _should_ provide 
both mechanisms. I have yet to hear a good argument about why DTCP 
should not provide the p2p and proxied logic. Having it in one place 
makes it easier for implementers since there is only a single protocol 
specification to implement -- they don't have to go pounding through 
other JEPs to do a bytestream. Resurrecting PASS doesn't really help 
the issue.

> Therefore, we propose the follwing change to the JEP: Instead of using
> arbitrary order, the given <host/>s should be tried in the order they
> where sent in the <iq/>. It's still allowed to try more than one host 
> at
> the same time, but it's not allowed to reverse the order of hosts.
> If more than one host is tried at the same time, it's up to the other
> peer (the one that knows which connection is 'cheaper') to accept the
> direct connection and refuse the PASSed one.

How do you propose that "the other peer" figure out which connection is 
cheaper? If I remember my Network Design classes correctly, you'd 
actually have to start talking with the routers to figure that out. In 
a scheme where peers are connected by a number of possible IP/ports it 
is not possible for either peer to know which IP/port is "more direct" 
without exchanging additional information not included in the DTCP 

I do agree that, at the very least, <host>'s should be tried in the 
order specified. I still don't understand this aversion to defining a 
fixed sequence of events for establishing the network connection.

> To summarize, this proposal allows relayed DTCP connections with 
> minimal
> changes to the current DTCP JEP, by use of the already existing PASS
> protocol. Clients that don't want to bother with PASS can safely ignore
> it, and a relayed connections are possible as soon as one of the 
> clients
> supports PASS.

Why abstract it out like that when you can benefit from having a single 
specification -- if a client supports DTCP then you don't have to worry 
about optional support for other JEPs.

> Diz

Version: PGP 8.0 (Build 349) Beta


More information about the Standards mailing list