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

RE: Comments on section 9.8, TRACE

From: Catalin Floristean <Catalin.Floristean@ohb.com>
Date: Wed, 27 May 1998 22:54:10 +0100 (BST)
Message-Id: <E1F03724556FD111826600805F85F52003798F@EXCHANGE1>
To: Dave Kristol <dmk@bell-labs.com>, artg@cs.nyu.edu
Cc: http-wg@cuckoo.hpl.hp.com, Louis Discepola <disc7701@sparky.cs.nyu.edu>, Catalin Floristean <floriste@slinky.cs.nyu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/148
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 :).


> -----Original Message-----
> From:	Dave Kristol [SMTP:dmk@bell-labs.com]
> Sent:	Wednesday, May 27, 1998 12:15 PM
> To:	artg@cs.nyu.edu
> Cc:	http-wg@cuckoo.hpl.hp.com; Louis Discepola; Catalin Floristean
> Subject:	Re: Comments on section 9.8, TRACE
> ...
> 2) I think the student is trying to read too much into the
> specification.  The description of the response says only that the
> request message should be returned as an entity.  It says nothing
> about
> checking the Request-URI or the resource so-identified  The topic of
> what to do when something is unstated often comes up in discussions
> here
> (and I often raise them :-).  If the specification doesn't say to do
> something anywhere, then don't do it.  In this case, a server might or
> might not check the syntax of the Request-URI, but it need not check
> the
> resource so-identified.
> ...
Received on Friday, 29 May 1998 06:25:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC