Re: Straw-man charter for http-bis

[Keith Moore <[e-mail]>]

> 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
fully read the specifications and just implement whatever seems to work.

Again, I'm not saying don't rewrite the HTTP spec.  I'm saying don't
underestimate the effort involved, or the harm caused by unintended
changes or the difficulty of comparing old and new specifications with
different structures.  And be really sure you understand how the rewrite
is going to benefit the community, taking into account that a lot of
implementors won't bother reading the spec and a lot of existing
implementations aren't going to get significant updates to conform to
the new spec.

> Personally, I don't care what color ribbon our pig wins at the county
> fair. :)
Even if it is cute enough to win a ribbon, do we really need another pig?

Keith