[standards-jig] DTCP Relay (proxy)
justin-jdev at affinix.com
Thu Dec 12 20:19:14 UTC 2002
On Thursday 12 December 2002 06:40 am, Dave Smith wrote:
> 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.
I think the problem is that it would make DTCP too low level. In all cases,
you would want a connection in both directions to be checked. This would
mean all higher level applications having to perform a special procedure, or
having to write some sort of wrapper JEP ("Reliable DTCP" ?) so that we have
a standard way of clients negotiating the connection that higher level
applications can use. See the redundancy?
> > - 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.
Even so, the idea of using PASS is not as bad as it sounds. I admit I had not
read the JEP fully until last night. Now I wonder how it got such a bad rap
in the first place. The old criticism about it using too many ports is
easily solved using the <oneshot/> option. The use of PASS allows everything
we want (compatibility with DTCP, end-to-end SSL, transparency to the
target), and is already an Active JEP! It almost seems too good to be true.
More information about the Standards