[standards-jig] JOBS using HTTP

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Fri Dec 13 02:22:23 UTC 2002


After one of the council meetings, where these streaming issues were
brought up, I was asked to ponder converting JOBS' out-of-band
communications from it's "proprietary" format to HTTP.  With some advice
from Thomas Muldowney and Ben Schumacher, here is a quick write-up of
what the OOB would look like:

1.A:  SENDER CONNECTS OOB
1) Sender requests connection to JOBS (HTTP):
------
PUT /sessionid/01234567 HTTP/1.1
JOBS-client: sender at domain/res

------

2) Service responds to client (HTTP):
------
HTTP/1.1 401 Unauthorized
WWW-Authenticate: JOBS confirm=123487650000

------

3) Sender confirms key (XMPP)
------
<iq type='set' from='sender at domain/res' to='jobs.domain'>
    <session id='01234567' action='authorize'>
        <item type='auth' action='confirm'>123487650000</item>
    </session>
</iq>
------

4) Service accepts key (XMPP)
------
<iq type='result' from='jobs.domain' to='receiver at domain/res'>
    <session id='01234567' action='authorize'>
        <item type='auth' action='accept'>995678432100</item>
    </session>
</iq>
------

5) Sender requests authorization to JOBS (HTTP):
------
PUT /sessionid/01234567 HTTP/1.1
JOBS-client: sender at domain/res
Authorize: JOBS accept=995678432100

------

6) Service accepts (HTTP):
------
HTTP/1.1 100 Continue

------

7) Sender starts to transmit data (HTTP)
------
PUT /sessionid/01234567 HTTP/1.1
...

------

1.B:  RECEIVER CONNECTS OOB

1) Receiver requests connection to JOBS (HTTP):
------
GET /sessionid/01234567 HTTP/1.1
JOBS-client: receiver at domain/res

------

2) Service responds to client (HTTP):
------
HTTP/1.1 401 Unauthorized
WWW-Authenticate: JOBS confirm=000012348765

------

3) Receiver confirms key (XMPP)
------
<iq type='set' from='receiver at domain/res' to='jobs.domain'>
    <session id='01234567' action='authorize'>
        <item type='auth' action='confirm'>000012348765</item>
    </session>
</iq>
------

4) Service accepts key (XMPP)
------
<iq type='result' from='jobs.domain' to='receiver at domain/res'>
    <session id='01234567' action='authorize'>
        <item type='auth' action='accept'>567843219999</item>
    </session>
</iq>
------

5) Receiver requests authorization to JOBS (HTTP):
------
GET /sessionid/01234567 HTTP/1.1
JOBS-client: receiver at domain/res
Authorize: JOBS accept=567843219999

------

6) Service accepts (HTTP):
------
HTTP/1.1 200 OK
...

------

More work needs to be done, but using HTTP for the out-of-band
conversation is definitely a feasible possibility.  Plus, the protocol
could fairly simply be extended to allow for SSL/TLS.


-  LW


On Thu, 2002-12-12 at 11:42, 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
> why.
> 
> --temas
> 
> http://www.w3.org/Protocols/rfc2616/rfc2616.html
> http://www.ietf.org/rfc/rfc2617.txt
-- 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)




More information about the Standards mailing list