[standards-jig] DTCP Relay (proxy)

Justin Karneges 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.

-Justin




More information about the Standards mailing list