The main benefit of caching will be when queues are introduced into the
SIP enhanced caches. This will ensure that certain important
notifications, such as "BYE" are not lost, even in the face of network
failures. Existing caches will obviously not be useful for this type of
information. However by using HTTP one can still communicate through the
proxy who will understand that there is nothing useful it can do here.
This is the behavior one expects of a proxy whenever it runs up against a
method it hasn't seen before.
>
> What's left is use of the proxy infrastructure, and absent caching,
> the main effect of that is to make it easier for SIP to slip through a
> firewall which is not specifically aware of it. Many security folks
> would call that a bug, not a feature.
>
That would be true if and only if the intention was to tunnel through
POST, it is not. The design I submitted previously and the one I intend to
submit in the future will use new method names so that they can be
properly secured.
The strongest motivation behind wanting to use HTTP for applications like
SIP is that it allows us to stop reinventing a lot of basic features.
HTTP's message format isn't perfect but it is good enough. HTTP's caching
features aren't perfect but they are smart enough to know when they can't
help, this lets us incrementally roll out a SIP infrastructure within the
current HTTP infrastructure. HTTP's security foundations are good enough
as is for many applications and there is a clear path to making them
better.
The bottom line is that SIP agreed enough with this analysis to actually
use HTTP in an almost compliant way. My intention is to make them fully
compliant and so allow users to leverage existing HTTP development
environments and to allow administrators to simplify their message
oriented infrastructures.
> rst
>
Yaron