[standards-jig] DTCP Relay (proxy)
dizzyd at jabber.org
Thu Dec 12 14:40:13 UTC 2002
-----BEGIN PGP SIGNED MESSAGE-----
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
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,
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
> 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
> 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
> 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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 (Build 349) Beta
-----END PGP SIGNATURE-----
More information about the Standards