[standards-jig] A Proposal to the DTCP/JOBS/PASS madness

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Dec 13 21:52:35 UTC 2002

Jer <jer at jabber.org> wrote on 13-12-2002 21:30:43:
>> I did some thinking last nite and have an idea on how we can deal 
>> with some of the outstanding issues facing the community. Let me now 
>> present my case..
>Excellent Diz, I go to sit down and write my own summary, and find out 
>you've already done one better, nice :)
>As was mentioned in the brief council meeting last night, using HTTP 
>as the standard mechanism still "downgrades" to a standard async 
>bytestream TCP socket using the standard CONNECT method in the HTTP 

What HTTP spec. are you referring to?

It's not in the HTTP/1.0 RFC"

It's not in the original HTTP/1.1 RFC:

But it's in the updated HTTP/1.1 RFC:

While HTTP works in almost all cases, the same can not be said for HTTP 

>What I also like about HTTP is that you don't need to transfer 
>any meta info about the file xfer, such as media, size, etc, you use 

You can see though, that the current path taken in most proposed 
implementations is to duplicate all that information outside HTTP. for 
example: http://www.jabber.org/jeps/jep-0052.html 

It's nice to have this, but how many people will actually implement it 

>that in addition to the plethora of proxies in the middle 
>(PASS-style works as well) and other software/libs that can be bolted 
>onto clients to hand off requests to.  There's also the possibility of 
>doing HTTPS, and even certificate auth for better security.
>I'd say that this is an excellent 80/20 solution, if not better, it 
>may not be optimal in some rare situations, but it's simplicity and 
>immediate usability will make up for it general file transfer use.  
>It's very much in line with the original OOB mindset *g*.

All together standardizing on HTTP GET/PUT for filetransfer, *and* 
CONNECT for async. could be ok I suppose, as long as there's still a 
decent framework around it to allow alternatives. Ofcourse additionally 
to just saying "we're gonna use HTTP" there has to be some staderdized 
form of authentication. 

And one more thing: will we support a sub-spec of HTTP/1.1 (kind of 
like XML-streams and XML) or the full spec.? (including Chunked 
Transfer Coding etc.) 

Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list