- From: Keith Moore <moore@cs.utk.edu>
- Date: Wed, 10 Mar 1999 00:31:39 -0500
- To: Yaron Goland <yarong@microsoft.com>
- cc: "'Keith Moore'" <moore@cs.utk.edu>, web@apps.ietf.org, discuss@apps.ietf.org
> As for layering, why do you believe this is a layering on top of HTTP? I still haven't had time to read the document myself... (and frankly, I'm hoping that others' reviews will either relieve me of the need to do so, or make it clear that it's worth my time to do so... gotta reduce the Apps ADs' workload somehow) > The draft expands HTTP in a direction that others, such as SIP, have already > gone. SIP already defines how to send SIP requests over unicast UDP and > multicast UDP. The only thing even mildly original about the spec is the > ANNOUNCE method which I suspect you can find strong parallels for in SIP. > ANNOUNCE is a fairly natural method to have once you have multicast support. ...however, I did do a fairly detailed review of SIP, and while I didn't find any outright technical flaws (that didn't get fixed) I sort of hope we don't invent more protocols like it. It's close enough to HTTP to make it tempting for people to implement SIP-over-HTTP, but it's also incompatible with HTTP/1.1, and as a matter of design choice rather than accident. I don't like the idea of people trying to layer lots of similar-but-slightly-different things over HTTP. I suspect the result will be that HTTP implementations will be (even further) burdened by hundreds of conditional flags in an attempt to be reusable by all of the different higher-level protocols, and/or that various implementations of these protocols will not adhere to the specifications where they differ from HTTP, and interoperability will suffer. And technically, HTTP/1.1 is a lousy protocol to use as a base for other protocols - its "Christmas tree" design history where lots of ad-hoc extensions from multiple vendors were piled on top of each other - makes it too complex. SIP inherits much of HTTP/1.1 complexity, without the ability (in general) to use HTTP libraries or servers to faithfully implement it. I find this design decision difficult to justify. so this isn't a comment on your proposal per se, but please don't hold up SIP as an example of something to be emulated. Keith
Received on Wednesday, 10 March 1999 00:43:31 UTC