Re: Updated proposal for OPTIONS issue

Jeffrey Mogul <> 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;
>   states that is not unconditionally compliant with
>   RFC9999, but does not imply that 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:
>   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