[standards-jig] Pondering DTCP

Justin Karneges justin-jdev at affinix.com
Thu Dec 12 20:47:53 UTC 2002

Hi temas,

> Well I've long been pondering DTCP and it's relation to what we
> generally use now in Jabber, HTTP.  I think it's important to note that
> I don't mean HTTP as the WWW, I mean HTTP as a solid protocol.  I'm
> failing to find a reason that we are abandoning HTTP in favor or something

The questions are:

1) DTCP has a set of requirements.  Is HTTP capable of meeting them?
2) If so, is the extra complexity worth the flexibility?

For #1, it is important to remember that DTCP uses a request/response and 
sometimes even a request/response/ack procedure in the handshake.  I don't 
think HTTP operates this way (at least in the latter case), and so it might 
take a 'hack' to get this to work.  Once connected, the stream must be 
bi-directional (if we wish to do anything beyond FT).  While it might be 
possible to have HTTP meet these requirements, I don't think any other 
application (other than our Jabber clients) would expect this kind of 
behavior.  After all, it is not like you are going to be able to open a URL 
for DTCP with Internet Explorer.  But then I have to ask:  why use an 
existing standard if we have to twist it?

For the sake of discussion, let's say we moved to using HTTP as the handshake 
protocol instead of the one used currently, bringing us to my #2 question.  I 
see our gain being a very flexible header system.  What kinds of header 
information could DTCP benefit from?

> my question on the table is, why are we turning our backs on HTTP?  I
> urge everyone to read the HTTP and related RFCs and share their reasons
> why.

At the simplest level, my reason to avoid HTTP is that it wouldn't gain us 
anything (other than the ability to say we are using a standard).  DTCP works 
very well according to the current specification.


More information about the Standards mailing list