[standards-jig] Pondering DTCP

Thomas Muldowney temas at box5.net
Thu Dec 12 19:42:32 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
else that is overly simplified.  The first obvious question that pops
into my head is why we want to leave behind all the excellent premade
HTTP libraries in favor of handwriting a whole new one.  Even if we had
to handwrite a basic HTTP library the semantics are more well defined in
the HTTP headers, and the method system is obvious.  The method system
is a point of contention though.  People have said that the GET/PUT
methods just don't make sense in relation to some usages.  Well, that's
fine, make new methods.  The HTTP RFC clearly indicates that extension
methods can be defined and used.  Proxying has been another large issue
when discussing stream methods in Jabber, and later I think this might
lead to cacheing issues.  The HTTP protocol has taken these into account
and has headers for proxy authentication, as well as a whole section of
the RFC devoted to cache control.  Finally we have the issue of
authentication and authorization.  HTTP has entire RFCs devoted to
authentication and authorization, plus it is easy to extend a new method
from it, if we think we need something that better fits with Jabber.  So
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.

--temas

http://www.w3.org/Protocols/rfc2616/rfc2616.html
http://www.ietf.org/rfc/rfc2617.txt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20021212/c3691412/attachment.sig>


More information about the Standards mailing list