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 DivisionReceived 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