[standards-jig] DTCP Relay (proxy)

Ben Schumacher ben at blahr.com
Fri Dec 13 01:46:32 UTC 2002

Hash: SHA1

Justin Karneges wrote:
| On Thursday 12 December 2002 03:01 pm, Ben Schumacher wrote:
|>Please accept this criticism from somebody who has been a network
|>administrator for several service providers before moving on to software
|>development. What you are suggesting will not work in the real world,
|>and the "bad rap" that PASS received was because of its failure to
|>provide a real world solution for the problem of NAT'd addresses and
|>tight firewalls. Let me explain further below.
| Criticism accepted.  This makes me wonder though, are the problems
here with
| PASS itself, or with the fact that DTCP and proxy are separate?  It
seems to
| me that this separation is a good thing, and if PASS is not acceptable
| we should need a PASS2 to address the problems.

I'm afraid I disagree with this. I don't think they are separate
protocols. Once we start designing a "PASS2" it become apparently there
there is too much overlap, too many areas where they are similar, to not
have them as one protocol. You will still need to do the same key
exchange that you are doing for DTCP in order to make a "PASS2"
connection. If they *ARE* separate protocols, you increase the
complexity, because this key exchange will have to happen twice (once
when I establish my "PASS2" connection with the server, and again
between the two end points on the "DTCP-over-PASS2" connection). What
does that give us?

|>The point is, saying that you don't want to deal with these things in
|>DTCP because its adds complexity is not sufficient. This issues need to
|>be addressed. The unfortunate thing is that expanding DTCP to address
|>all of these problems will most likely ultimately end up being very
|>similar to JOBS, and there will be a lot of lost time because some
|>parties have decided to be stubborn and not work together.
| Ok, do you have a suggestion?
| Perhaps we can find a way to improve DTCP-Relay (see the
thread-parent), but
| avoid turning it into JOBS.

Yes. My suggestion is that you look at JOBS. I have yet to hear a
technical reason why JOBS is insufficent, and what DTCP gives us that is
better. The only complaint I've ever heard from you (or anybody) is that
its too complex, yet nobody has proposed how to make it simpler and
still maintain the high level of functionality it provides. On ther
other hand, you're now suggesting we take two related problems and come
up with unrelated solutions. How is this supposed to simplify things?
Instead of implementing one unified protocol, I now how to implement
two? That gives me more areas where mistakes can be made.

Complexity isn't necessarily a bad thing, take a look at MUC as an
example. Its a complex solution to a complex problem, but it is well
documented. I would suggest that JOBS is an analogous example, while the
protocol is somewhat complex (although I don't think its nearly as bad
as you would lead somebody to believe), it solves a complex problem in
an elegant matter, but its well documented, thanks to the efforts of
Matthew Miller.

I looked at you proposed DTCP-Relay, and I will reiterate the point I
made in my previous post... it seems to contain a lot of hand waving,
with no real solution.



Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Standards mailing list