- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Thu, 7 Aug 1997 12:13:31 -0700
- To: 'HTTP Working Group List' <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
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 all. 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 capability? 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