W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1997

Re: Comments on OPTIONS draft

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Thu, 7 Aug 1997 12:13:31 -0700
Message-Id: <01BCA32B.528C9F40.ejw@ics.uci.edu>
To: 'HTTP Working Group List' <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4108

An addendum to my previous post:

Roy was kind enough to point out to me that RFC 2068, in Section 1.2, 
contains definitions of "unconditional" (all MUST and SHOULD) and 
"conditional" (all MUST) compliance, which removes some of my objections 
(points #1 and #2) for RFC 2068.  However, other RFCs (notably RFC 1945) do 
not have such definitions, and for these RFCs my criticisms still hold.  In 
fact, since RFC 1945 (shown in examples in the draft) is an informational 
RFC, it is unclear whether it should be listed in a Compliance header at 

The definitions of unconditional and conditional in RFC 2068 do not remove 
all ambiguity -- for example, the Range header is listed as a "MAY" 
capability in RFC 2068, but "origin servers and intermediate caches SHOULD 
support bytes ranges."  So, is the Range header an unconditional 

Plus, I would still like to have the ability to have new protocols define 
their own option tokens.

- Jim
Received on Thursday, 7 August 1997 12:22:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC