Re: Rechartering HTTPbis

On Sat, Jan 28, 2012 at 12:37:35AM +0000, Poul-Henning Kamp wrote:
> I hate to be nasty about this, but the fact that HTTPbis made
> RFC2616s page-count double is a major fiasco in my eyes, and I do
> not really consider the result an improvement over RFC2616 in any
> significant way.

I don't see this as a fiasco, quite the opposite in fact. We spent a lot of
time and used a lot of words enumerating corner cases and giving
recommendations in order to expose known corner cases. Precisely because the
original spec was not precise enough. If we'd had specific MUST/MUST NOT in the
original spec concerning strict parsing, multiple Host/Content-length header
processing, how to handle ranges or set-cookie, etc... http-bis would be much
smaller and possibly wouldn't exist. So I'm in favor for strict rules before
small size, even if the strict rules result in more pages. It's also important
to explain the intent of some unclear design choices so that when people
implement them, they don't blindly code something they can't even test but
instead they apply appropriate error processing for their context.

> Yes, things have been clarified, and explained, but the matter
> of the fact is that HTTP/1.1 sucks as protocol engineering, and
> no amount of lipstick or explanations can change that fact.

It will not change that fact but we're basically drawing a map of all known
landmines so that implementers save their legs. We all know how it sucks to
be an implementer and we all know that we're permanently tempted by this
tradeoff between complexity and usefulness resulting in "oh I don't need
that anyway, let's skip those 3 pages and cross fingers". That's why the
design intent is sometimes important to convince implementers to do something
apparently useless to save their butt.

> Otherwise it will just be IPv4 vs. IPv6 all over again.

IPv4 vs IPv6 is not a matter of spec size, but a matter of complexity to
convert a lot of application code which used to stuff IPv4 addresses into
integers and function return values (eg: inet_addr()).

> If we start out at 29 pages, that means we'll end just shy of
> 100 pages, which is a bit over the top, but livable.

3 days ago I have printed p1, p2 and p7 on 2 per-page and 2 sides, without
the changelogs, to review the text. It's not that big, I carry it everywhere
with me and it's not even heavy. BTW  I think that the split is really a good
thing because we don't need all parts. Transport and contents are two things
different enough to be split.

> PS: Feel free to call me a grumpy old man.

Come on, your uptime is far from wrapping. I'm sure there is even a
fair number of participants with bit 6 set in this WG :-)

Regards,
Willy

Received on Saturday, 28 January 2012 07:44:53 UTC