[standards-jig] Pondering DTCP
justin-jdev at affinix.com
Thu Dec 12 20:47:53 UTC 2002
> 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
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