Such a scalable design! How wonderful and elegant. We will all
submit our new method names to the Jester, who will approve them
and define them.
Such a reliable design! Method names never change! Methods never
evolve, so that there is never a case where an old, secure method
suddenly has a new insecure meaning! Methods are like rocks! Solid,
unmoving!
The method-name is one of the most fragile of HTTP's extensibility
mechanisms; between new method, new URI, new URI scheme, new protocol
name, new header, new header value, new content-type, I think "new method"
has some of the least attractive properties: highly variable behavior
when encountering new methods by proxies and existing servers, no
registry or mechanism for conflict avoidance, no migration path for
new versions, and a pretty poor track-record.
You're better off just POSTing to new URIs, at least then it's clear
what the extensibility path might be. If that doesn't work, then create
a new URI scheme, there's already a 'noreg' way of keeping them separate.
> 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.
Oh, like RPC! Like 30 years of networking research! Why don't we
stop reinventing that, too?
Like defining protocols that are robust against exceeding the
size barrier of UDP! Let us not reinvent that, either!
> HTTP's message format isn't perfect but it is good enough.
Good enough for what, precisely? Not good enough for the basis of
reliable, lightweight, scalable, and robust networking services, at least
not those based on UDP and multicast. There's not even a request-ID
for matching against responses.
Oh well, I suppose 99% of the time, requests are mainly delivered
in order and responses are returned in order, and, hey, if it fails 1%
of the time, who cares? Isn't that 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.
Uh, right, the protocol features are smart enough to get out of
the way, in about 60% of the deployed caching servers. As for the
rest of them? Well, screw 'em, they're running someone else's
software, so it doesn't matter. Serves them right.
> HTTP's security foundations are good enough
> as is for many applications and there is a clear path to making them
> better.
The sky is a clear path, but it has no boundaries. There is no
"clear path" for making HTTP robust and secure as a mechanism for
peer-to-peer communication initiation or even service location.
> 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.
Finally, back to where the thread started:
It's a fine goal to try to design some convergence of SIP and HTTP
such that they could use the same infrastructure, such that some future
revision of Apache could do both. but that's very different from
the assertion that new SIP services could use _existing_ HTTP proxies,
firewalls, clients, or implementations without change.