Re: Another try at OPTIONS

Scott Lawrence wrote:
> 
> >>>>> "Henry Sanders (Exchange)" <henrysa@EXCHANGE.MICROSOFT.com>:
> 
> HS> This proposal sounds good, except for the bit about having a
> HS> Compliance:  header on any request. I really dislike that part -
> HS> it's just one more thing for the server to have to check for and
> HS> deal with on every request. What's the rationale behind that? I'd
> HS> much prefer to see it specifed as only applicable to OPTIONS.
> 
>   For the time being (that is, the next version of HTTP/1.1) I think
>   that introducing Compliance (and possibly Non-Compliance) as a
>   header to be used with OPTIONS is sufficient.  If we do not define
>   any behaviour for it with other methods, future versions of HTTP can
>   attempt to do so based on experience with the many new aspects we
>   are defining.
> 
I agree, it opens too many cans of worms.  As a clarification to scott's
previous remark about Jeff's changes to my OPTIONS spec, I agreee with 
those changes, to make the OPTIONS use a header instead of the request
body.

By using the header, we have made it possible for this issue to
come up, using the compliance with a non options request.

The original motivation I had to write the OPTIONS clarification/spec
was to allow a simple, required mechanism to detect extensions in
HTTP/1.1
which would be in the spec.  I specifically avoided making it very 
complicated to avoid the difficulties that PEP has faced.
PEP is very flexible and powerful, and I beleive, a "good thing".
However that complexity is something that has kept it from 
being included in HTTP/1.1. So, rather than rush PEP or cobble
together a subset of it, it seems that a baseline OPTIONS is
needed in the protocol, as a MUST.

Sine PEP can do what the compliance header w/ non options method can
do, I beleive we should leave that alone, and not define 
compliance: header behavior with non OPTIONS messages.

Additionally, excluding the goals of PEP, the reasons I can think
of for using compliance: with a non OPTIONS method can be addressed
by existing headers such as upgrade:...


-- 
-----------------------------------------------------------------------------
Josh Cohen				      Netscape Communications Corp.
Netscape Fire Department	           	     #include<disclaimer.h>
Server Engineering
josh@netscape.com                         
http://people.netscape.com/josh/
-----------------------------------------------------------------------------