[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 
>spec.

What HTTP spec. are you referring to?

It's not in the HTTP/1.0 RFC"
http://www.w3.org/Protocols/rfc1945/rfc1945

It's not in the original HTTP/1.1 RFC:
http://www.w3.org/Protocols/rfc2068/rfc2068

But it's in the updated HTTP/1.1 RFC:
http://www.w3.org/Protocols/rfc2616/rfc2616.txt

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

>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 
>HTTP HEAD,

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 
too? 

>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