Re: Updated proposal for OPTIONS issue

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"
parameter.

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