Re: Comments on OPTIONS draft

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Dave Kristol: "draft-ieft-http-options-00.txt"
• Previous message: Koen Holtman: "Re: Using Content-Encoding and Content-Disposition together"
• Maybe in reply to: Jim Whitehead: "Comments on OPTIONS draft"
• Next in thread: Jeffrey Mogul: "inconsistent use of MAY & SHOULD in 14.36.2 Range Retrieval Requests"
• Reply: Jeffrey Mogul: "inconsistent use of MAY & SHOULD in 14.36.2 Range Retrieval Requests"

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

• Next message: Dave Kristol: "draft-ieft-http-options-00.txt"
• Previous message: Koen Holtman: "Re: Using Content-Encoding and Content-Disposition together"
• Maybe in reply to: Jim Whitehead: "Comments on OPTIONS draft"
• Next in thread: Jeffrey Mogul: "inconsistent use of MAY & SHOULD in 14.36.2 Range Retrieval Requests"
• Reply: Jeffrey Mogul: "inconsistent use of MAY & SHOULD in 14.36.2 Range Retrieval Requests"