Re: Straw-man charter for http-bis

> That's exactly the argument. If a "more substantial" rewrite does a
> better job of documenting HTTP, we should consider it. This
> possibility shouldn't cause discomfort, because our shared goal is to
> accurately document HTTP 1.1, right?
The catch is that HTTP is (currently) specified by RFC 2616, and the
most accurate documentation about HTTP is in RFC 2616.  If you replace
2616 with a completely different specification, you're not "accurately
documenting" HTTP, you're _changing_ the specification.   You will
inevitably create incompatibilities between "old" HTTP and "new" HTTP.

I'm not saying it's inherently a bad idea to do that, I'm saying that a
rewrite is going to cause some interoperability issues even if you end
up with a much clearer and/or more precise specification.

People contemplating a rewrite of HTTP should really look hard that the
experience from the DRUMS working group that updated RFC 822 and SMTP. 
It took a very long time, and while the results are clearer in many ways
than the original specifications, IMHO they are not an improvement in
every respect.  For instance, a lot of effort was spent in  rewriting
the ABNF that describes internet messages.  The new ABNF is perhaps more
precise but it's _much_ harder to write a correct parser for the new
grammar - and there's very little benefit to doing so because new mail
readers still need to be able to parse pre-RFC2822 messages.  So in
practice, to write a good mail reader, you now need to refer to BOTH RFC
822 and RFC 2822 - because the RFC 822 grammar is the best one to write
a parser from, and 2822 has the grammar that you should use when writing
code to generate new messages.   (And they're in different notations!)
This means _more_ work for the implementor, a higher barrier to
producing a correct  implementation, and a greater temptation to not