Re: An experiment in producing RFC1122-style requirements checklist

http-wg@cuckoo.hpl.hp.com writes:

>This proposal of mine raised several questions:
>       (A) is this kind of checklist really useful?

Yes, it's useful.  When my team implemented HTTP/1.0, we used the
(then-draft) RFC in exactly this way, reading it cover to cover several
times, with each of us extracting items we thought belonged on a
checklist and merging the results.

>The table below follows the modification of the RFC1122 format.  I.e.,
>rather than follow that format exactly, I made separate columns for
>Server, Proxy, and Client requirements.

Thank you!  There really are at least two and possibly three major camps
in HTTP, split just this way.  Lots of us are in the server business,
a smaller group are writing clients, and then there are the masochists
who've undertaken proxies.  Given the amount of proxy/cache detail in
HTTP/1.0, having a column for those poor souls has to be a good idea.

>                                      I'm assuming that implementors
>will be able to deal with a checklist that isn't carefully organized
>into topic areas, but I suppose there is no real reason why this
>has to be done in strict section-number order (which is what I've
>done so far).  Comments on whether the table should be in strict
>section-number order are welcome, although the alternative might
>lead to a lot more work for the editors (i.e., we might not feel
>like spending the time).

I could accept section-number order, in fact I'd like it better
than someone's semi-personal choice of topics.  But if analyzing 10%
of the RFC produced 38 checklist items, then this checklist can be
expected to run something like 6.3 pages single-spaced without
whitespace.  That's more than most humans can cope with - some sort
of organization beyond the arbitrary section numbers is going to be
needed.

Ross Patterson
Sterling Software, Inc.
VM Software Division

Received on Friday, 30 May 1997 06:17:49 UTC