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

> I believe that the argument in favour of HTTP is not that it is a protocol
> ideally suited to the requirements of SACRED but a pragmatic one.  Many
> SACRED platforms already support HTTP and since it can be used for our
> needs then if SACRED is to be widely accepted it will probably need to
> support HTTP as a transport.

this is a misconception.  the fact that HTTP is already supported on
some of the SACRED platforms does not mean that it is easier to use
HTTP than to use another protocol.  HTTP actually gets in the way because
its framing and error reporting are not what you need for SACRED, 
and because HTTP caches and firewalls actually degrade interoperability.  
Put it this way: those same platforms implement TCP, and TCP is a better
fit for what SACRED needs than HTTP.

> > but there are other problems with HTTP.  it's completely unacceptable to
> > reuse port 80 or http: URIs for a new application, and bypassing site
> > security policy (e.g. firewalls) is NOT a legitimate goal.
> 
> I can see that SACRED would be a new service and so should use a new port
> etc but it can't be the only protocol considering using http in this way
> (CMC and CMP have documented HTTP as a binding and do not seem to tackle
> the reuse of port 80 or http: scheme).

I'm not sure what you mean by CMC and CMP but IETF has not standardized
another application using port 80, and I suspect they are extremely unlikely
to do so.  AFAIK the only other application IETF has standardized using
HTTP is IPP, and that was a huge mistake - resulting in unnecessary complexity 
and delay in defining IPP with no measureable benefit.
 
Keith