W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Re: Comments on section 9.8, TRACE

From: Dave Kristol <dmk@bell-labs.com>
Date: Thu, 28 May 1998 10:56:06 -0400
Message-Id: <356D7B06.7F43@bell-labs.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:18 EDT