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

> One of the reasons for using HTTP is that we will be able to re-use the
> existing infrastructure etc and not having to invent our own framing which
> we would have to do if we went the TCP route.

you end up inventing your own framing anyway, but it's more complex if
you have to layer it over HTTP. 

> Can you explain why HTTP's framing is not suitable?

each HTTP transaction is separate.  there is no assurance that multiple
HTTP transactions for the same request-URI share the same TCP connection
or even that they get sent to the same host.  HTTP caches may route them
differently.

The other reason that it is not suitable is that with HTTP you have to 
do extra work - by adding headers - to discourage caches from interfering 
with your payload.  the existing infrastructure for HTTP doesn't help you; 
rather, it gets in your way.

TCP gives you a bidirectional sequence of octets, with order preserved
(without doing stop-and-wait), duplicates suppressed, and clean termination.

HTTP gives you the ability to make requests of a URI, with no assurance
that order will be preserved unless you do stop-and-wait, no duplicate
suppression, and no assurance of clean termination.  HTTP has more overhead
than TCP and is a poorer match for SACRED than TCP.  And unlike IP routers,
HTTP intermediaries are likely to modify the payload in undesirable ways.

Keith