- From: Dave Kristol <dmk@bell-labs.com>
- Date: Thu, 28 May 1998 10:56:06 -0400
- To: Catalin Floristean <Catalin.Floristean@ohb.com>
- Cc: artg@cs.nyu.edu, http-wg@cuckoo.hpl.hp.com, Louis Discepola <disc7701@sparky.cs.nyu.edu>, Catalin Floristean <floriste@slinky.cs.nyu.edu>
Catalin Floristean wrote: > > I would just make a general comment here: it is true that in most > cases it is easy to infer > common sense answers to these questions, e.g. it is common sense not > to check the resource > identified by the Request-URI of a TRACE request. The point is though, > for some reason I still believe > that a good, solid specification should rely less on common sense > answers and more on clearly stated > definitions, descriptions, terms etc. (even if this implies a > reasonable amount of redundancy). I believe > this leads to a rapid and reliable implementation (and that's how you > get a big, ugly, hard-to-read yet > complete ANSI standerd :). If you're referring to the ANSI C standard, I had a small hand in that. :-) The danger with adding redundancy, as I found out from the ANSI C effort, is that it's very easy to introduce inconsistencies. If you say, "Do a, b, and c" in one place and "Do a and b" in another, you invite incompatibilities. The safest way to write a standard that's consistent is to say each thing only once, if possible. As with the ANSI C specification, you cannot understand the HTTP specification by looking at just one part. Unfortunately you have to understand all or most of it as a unit. Dave Kristol
Received on Thursday, 28 May 1998 08:00:40 UTC