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

Re: Updated proposal for OPTIONS issue

From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
Date: Wed, 30 Jul 97 15:26:10 EDT
Message-Id: <199707301934.AA12406@reston.vmd.sterling.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4028
Jeffrey Mogul <mogul@pa.dec.com> writes:

>Good point. I think interpretation #2 makes more sense, since
>the proxy could have sent
>       Non-Compliance: MyNameSpace=MyThing@Somebody.Else.Proxy
>if it meant #1.

Cool, although I was kinda hoping for a "Whoa!  We didn't mean for
parameters to be supported on Non-Compliance!"

>   For example, a response with:
>          Compliance: rfc=9999;uncond
>          Non-Compliance: rfc=9999;uncond@proxy.foo.net
>   states that proxy.foo.net is not unconditionally compliant with
>   RFC9999, but does not imply that proxy.foo.net is not
>   conditionally compliant with RFC9999.  If the proxy is not even
>   conditionally compliant with RFC9999, it should instead send
>          Compliance: rfc=9999;uncond
>          Non-Compliance: rfc=9999@proxy.foo.net
>   when forwarding the response.

I guess this means that a client needs to sort out all the Non-Compliance
headers it receives from proxies in a response and determine for itself
how parameters interact.  COND and UNCOND will probably be OK, but I
wonder about other parameters, especially the ever-present "token"

I guess I weigh in as thinking that parameters should not be permitted
in Non-Compliance headers.

Ross Patterson
Sterling Software, Inc.
VM Software Division
Received on Wednesday, 30 July 1997 12:34:08 UTC

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