Re: (revised) HTTP working group status

>I believe that HTTP 1.x is near the end of its evolutionary life as a
>protocol.  Most of the things people want to do with the web either
>can already be done with HTTP/1.1 or else are so completely beyond its
>capabilities that some other protocol family is needed (RealAudio,
>Internet Telephony, etc.)  I think dramatically better performance,
>security and reliability also require substantial incompatible
>protocol changes.

I disagree, there are many extensions that are possible within the 
HTTP/1.x framework. The fact that non has been raised on the
list is hardly suprising, during the finalisation of the 1.1 draft 
it was made very plain to those of us who wanted to extend HTTP
functionality that it was not a good time to bring it up.

I think that rather than introducing new protocols we need to 
introduce new classes of application that exploit the existing
capabilites of HTTP. There has been relatively little exploration
of the editing browser concept. With the exception of NaviPress
most HTML editors have failed to implement POST for example.

Adding security to HTTP need not involve enormous complexity.
I'll not name the vendor who I discussed signing of documents with
and got the respone "Oh you are still using PKCS#1? we are up to 
PKCS#7!", point is that some people seem to get caught up in
mystification.


We can add signatures to HTTP very simply with one tag :-

Content-Signature: <key-uri>; alg=DSA; value=<base64crud>


Content signatures are really just assertions concerning an entity.
If one introduces a wrapper into the protocol one can make 
assertions about an entity and its meta-data.

Clearly this is a class of secuirty that SSL and other systems that
attempt to hack the session layer can never provide. It is
unnecessary to apply the excessive mechanism that S-HTTP involves
simply to provide non repudiation of an action.


		Phill

Received on Monday, 19 August 1996 19:25:30 UTC