RE: need a reviewer (or three) for draft-cai-ssdp-v1-00.txt

Actually, I was very unhappy with SIP for reasons I doubt you would agree
with. =) I thought SIP should have just run on top of HTTP/1.1. In fact, I
wrote up an entire series of posts explaining exactly how to do this.

The point I was making, however, is that adding (unicast | multicast) UDP
support to HTTP is a very natural progression as demonstrated by SIP.

In generally I have found HTTP to be a wonderful platform to leverage and
far from finding myself having to do weird things in order to keep
everything working I have, more often than not, found that HTTP already
provides 99% of whatever I need and I only need to add a tiny extra bit to
get me where I want to go. I also find that when I add that 1% in one place,
I end up re-using that 1% over and over again in many other places.

In fact I have only one serious complaint about HTTP, which has nothing to
do with the spec. Most systems put very severe restrictions on the size of
HTTP headers (2k or less is common). So I often find myself having to put
information into the body of a request that I would have much rather put
into a header.

Outside of that, I am an extremely satisfied customer of HTTP and definitely
intend to continue investing in it.

		Yaron

P.S. As for HTTP's complexity. HTTP itself is an unbelievably simple
protocol. The problem is that it has inherited a lot of cruft over the
years, 99.99% of which is optional and not widely supported. I believe that
what the world really needs is a re-written version of the HTTP spec. One
organized into a more rational structure which shows the true beauty of
HTTP's layered architecture. I would be willing to bet that one could write
a spec providing the absolute bare minimum information needed to create a
compliant client/proxy/server in 20 pages.

> -----Original Message-----
> From: Keith Moore [mailto:moore@cs.utk.edu]
> Sent: Tuesday, March 09, 1999 9:32 PM
> To: Yaron Goland
> Cc: 'Keith Moore'; web@apps.ietf.org; discuss@apps.ietf.org
> Subject: Re: need a reviewer (or three) for draft-cai-ssdp-v1-00.txt 
> 
> 
> > 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 16:03:08 UTC