[standards-jig] Pondering DTCP

Matthias Wimmer m at tthias.net
Thu Dec 12 20:31:06 UTC 2002

Hi Thomas!

Thank you for your mail. I liked it very much. I already thought that 
I'm the only one that preferes existing well tested protocols over 
reinventions. The problem with having DTCP as a JEP is that implementors 
could thing that using http is depreciated and they should better 
implement DTCP.
Also I don't like IBB (and have blocked it with a JSM module in my 
Jabber server). If users can't connect to each other with a direct 
connection I'D prefere to set up a http server where they can put their 
files and send the URL to the other user.
Maybe we should write a simple introduction to http with pointers to the 
RFCs. Most implementors that want to invent something else don't know 
how easy http can be implemented (if you don't want to use an existing 

Tot kijk

Thomas Muldowney wrote:

>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

Fon: +49-(0)70 0770 07770	http://matthias-wimmer.de/
Fax: +49-(0)89-312 88 654	jabber://mawis@charente.de

More information about the Standards mailing list