Re: Size of the Spec Was:Re: Beyond 1.1

>There are two distinct issues -
>	- size
>	- layers (or separable protocols)
>
>I would propose that the HTTP/1.1 spec should be split
>more because of the latter than the former.

While it would be nice to have better arrangement of the spec I think
that Jim et. al have been doing a very good job on this front. The
HTTP/1.1 document is a lot clearer than earlier editions.

I think this is a presentation and not a protocol design issue. The
spec does have a clear separation of the various aspects of the 
protocol. I don't think that separating it out into four separate
documents would make it easier to implement or understand. I think
that the separations you describe have been addressed already.

The complaints I have seen have been about the size of the spec,
not its organisation. I don't think that the size is unreasonable 
for the functionality the spec delivers, nor do I think that the 
spec is over complex. If I did I would have been complaining
loudly at the time.


>We can simply spec a new version, and deal with backward compatibility 
>or reduced-function translators until the phaseover is complete.
>This is a poor argument for inertia, ever since version numbers have
>been included in protocol specs.


I don't think that such a move would simplify the spec at all. In fact
I can think of few ways to make implementation more onerous and error
prone. If you introduce a new basis for the protocol you will force
implementors to code both. Getting rid of HTTP/0.9 took long enough
despite there being less than 100 servers when it was superceeded.

I think that we can implement syntactic changes such as Paul's 
header compression hack. But the scope for such changes is limited.
If we attempt to change the semantics of HTTP then we will end up
in the sendmail problem. Whatever extensions are proposed the spec
will be rooted in the past by an installed base of software whose
architecture is inadequate to extend it. 

Look at the various "replacements" for CGI. Much of the installed 
infrastructure of the Web is now in plug in modules of one kind
or another. Most API replacements for CGI provide parsed headers in 
some sort of table indexed by the header name. Such implementations
can probably be adjusted to cope with Paul's proposal but I don't 
think that they could be adjusted to cope with very much more.

I think that at this point we should look to the functional 
improvements possible in HTTP/1.2 and then look at any architectural
changes necessary. I don't think that it will be very fruitfull to 
launch an attempt to reduce the size of the spec. 


		Phill

Received on Thursday, 8 August 1996 11:53:00 UTC