This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BD8997.BB77A790 Content-Type: text/plain 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 :). --Catalin > -----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. > > ... ------ =_NextPart_001_01BD8997.BB77A790 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
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 :).
--Catalin
-----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.
...
------ =_NextPart_001_01BD8997.BB77A790--