Re: SACRED over HTTP (was: RE: sasl in beep or payload)

> > If you want to exchange multiple PDUs per transaction in HTTP, you
> > essentially have to have each request (except the first) PDU contain a
> > state identifier which was provided in the last response PDU received.
> >
>
> I don't see why carrying the sasl payload assumes a persistent connection
> since, as Keith points out, we cannot assume this.  Part of the HTTP
> binding document would be a definition of how state is maintained.  I
would
> expect that this would probably be done by adding an extra wrapping layer
> to the PDU (which seems to be what Keith is suggesting) rather than by the
> use of cookies (RFC2964 and RFC2965).

time for a reality check: why don't you flesh out the actual protocol you're
talking about here that you're going to end up layering on top of http.

having gone through this exercise many times before, i think you will find
that you are adding 15-20 pages of spec to deal with administriva that you
get for free with beep and that you'll have to implement over http, thereby
negating much of the value from the 'reuse http' arguments.

if you could count on persistent connections, the problem you seek to solve
would merely be "hard but tractible", by having to manage state across
multiple sessions for the purpose of authentication, it has become
"problematic"...

/mtr