Re: Comments on OPTIONS draft

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