> On the UDP issue, several groups, including IMPP, GENA and UPnP have all
> had to do work on HTTP over UDP.
There is no mention in IMPP of "HTTP over UDP".
There is no GENA group, and the only reason why UPnP had
to do work "on HTTP over UDP" is, well, because you said so.
> Last week at the UPnP Forum I presented a
> summary of three drafts I have written. The first is HTTP over multicast
> and unicast UDP.
"HTTP over UDP" is an oxymoron. What you must mean is "A protocol,
borrowing from HTTP, but designed to work with UDP".
> The second is a new version of the GENA spec which is
> stripped down a bit.
I suppose you could say that "event notification" fits into PnP, but
only barely.
> The third is a new version of the Simple Service
> Discovery Protocol (SSDP) spec which is based on the previous two. All
> three should show up in the ID directory sometime next week.
And thus "submitted to the IETF for approval as a standard"?
> As for the other issues, absolutely SIP introduces new features into HTTP,
> as well it should. The reason for wanting SIP running over HTTP is that
> there is no reason that normal SIP communications should be prevented from
> flowing through normal HTTP firewalls and proxies on their way to SIP
> enhanced proxies. All the normal HTTP authentication and caching
> infrastructure would still apply.
Uh, right, the "normal HTTP authentication infrastructure" being "almost none".
HTTP can get away with almost no authentication infrastructure only insofar
as it's used for web browsing of mainly public information. Most of the
normal HTTP authentication infrastructure is useless for protecting resources
from denial-of-service, spam, unwanted monitoring; that's why IPP had a hard
time, and SIP and UPnP-over-HTTP should too.
And besides, "the normal HTTP authentication infrastructure" doesn't
sit well with UDP, does it? Now where *did* I see that Internet Draft
for UDP-based TLS?
> ........In addition using HTTP allows for SIP
> end points to be written using normal HTTP development environments. I for
> one believes this is a compelling advantage for administrators and
> developers.
>
> I haven't felt this level of righteous indignation since an old boss told
> me that WebDAV was a waste of time.
Me too. Except that the righteous indignation is about a headfirst
tumble into unreliable, non-scalable, insecure, inefficient, and otherwise
poorly-thought-out network protocols because the marketplace decides.
At least pet rocks were reliable, at least as rocks.
Larry